staging.inyokaproject.org

12. Juli 2020

Grundsätzlich war und bin ich ein großer Freund von S/MIME. Nicht weil ich etwas gegen PGP/GPG habe aber S/MIME wird in allen E-Mail Clients standardmäßig unterstützt und PGP/GPG musste man bisher bei allen verbreiteten Clients (Outlook, Thunderbird, Apple Mail) nachrüsten.

Leider hat Let's Encrypt bisher keine S/MIME Zertifikate im Angebot und die Möglichkeiten für kostenlose Zertifikate bei anderen Anbietern werden immer weniger. Bei meiner letzten Überarbeitung gab es noch WiseKey, secorio und Comodo (siehe: E-Mails mit S/MIME verschlüsseln). Secorio bietet nun nur noch kostenpflichtige Zertifikate, WiseKey hat kein vertrauenswürdiges Root-Zertifikat mehr und Comodo scheint es ebenso nicht mehr zu geben.

Die letzte bekannte Stelle ist nun Actalis. Allerdings mit einem erheblichen Nachteil, auf den auch Frank Zöchling zu recht hinweist. Die Keys werden nicht lokal beim Benutzer generiert sondern auf den Servern von Actalis. Sofern diese Firma den privaten Schlüssel speichert - was sich von außen weder bestätigen noch falsifizieren lässt  - können sie natürlich auch die verschlüsselten E-Mails entschlüsseln. Im Bereich der Verschlüsselung ist so etwas für mich ein absolutes Ausschlusskriterium. Auf diese Weise hat die Verschlüsselung nur noch eine Alibi-Funktion.

Damit bleiben nur die kostenpflichtigen Zertifizierungsstellen und welche Privatperson gibt dafür schon Geld aus. Das Netzwerk der Kommunikationspartner mit denen man verschlüsselt per E-Mail kommunizieren konnte erodiert somit weiter.

Damit bleibt eigentlich vorerst nur noch PGP/GPG (siehe: E-Mails mit OpenPGP verschlüsseln). Sofern man überhaupt noch E-Mail Verschlüsselung betreibt. Bei mir spielt das quasi keine Rolle mehr. Die Metadaten liegen bei allen Verschlüsselungsmodellen offen und die wirklich schützenswerten Inhalte - nämlich die Anhänge - kann man mit viel weniger Aufwand separat verschlüsseln.


Bilder:

Einleitungs- und Beitragsbild von mohamed Hassan via Pixabay

"

Die Möglichkeit Apps auf einem Gerät zu installieren, dass Menschen immer bei sich haben ist vielleicht die größte und folgenreichste Entwicklung in der Consumer-IT der letzten 20 Jahre. Fehler und Versäumnisse haben zu einem Duopol aus Apples iOS und Googles Android geführt und die Geräte werden immer mehr zu proprietären Schaltzentralen.

Ich persönlich würde meine Smartphone-Nutzung als verhältnismäßig konservativ bezeichnen. Ein Smartphone benötige ich primär für Messenger, E-Mails, Telefonie und PIM. Zusätzlich noch für Podcasts und einen RSS Reader und um schnell Fotos schießen zu können. Die meisten anderen Sachen rufe ich direkt im Browser auf und installiere dafür keine extra Apps. Denn im Browser greift ein Inhalteblocker, während die meisten Apps um die Krone in der Rubrik "Wer hat die meisten Tracker" wetteifern. Entsprechend geben die digitalen Achtsamkeitsberichte auch eine relativ geringe Nutzung pro Tag her.

Dies ist ein Nutzungsprofil, das einen verhältnismäßig einfachen Wechsel zwischen Systemen und mit einigen Abstrichen sogar zu AOSP oder komplett freien Systemen ermöglicht.

In den vergangenen Jahren ist das Smartphone jedoch zunehmend zur Schaltzentrale für diverse Dienste geworden. Aus Sicht der Anbieter ist das nachvollziehbar. Die meisten Kunden haben ein solches Gerät und sie können es oftmals besser bedienen als einen herkömmlichen PC. Das setzte aber eine Entwicklung in der Gang, der man sich kaum - oder nur mit erheblichen Einschränkungen - entziehen kann.

Unproblematisch sind solche Dienste, die auf freien und offenen Standards beruhen. 2FA über OTP Apps kann ich auch über ein AOSP mit einer entsprechenden App aus F-Droid erledigen und setzt keinen Zugriff auf die geschlossenen Hersteller-Stores voraus. Solche Dienste sind allerdings in der Minderheit.

Problematisch sind schon die ganzen proprietären Messenger, deren Benutzung in vielen Kontexten unumgänglich ist. Große soziale Netzwerke (im realen Sinne und nicht die so titulierten Onlinedienste), die ausschließlich via Telegram oder Signal funktionieren halte ich persönlich für einen Mythos.

Hinzu kommen weitere Dienste, die gar nichts mehr mit klassischen Handys oder Kommunikation zu tun haben. Ein erster Schritt in diese Richtungen waren die proprietären Banking-Apps für die TAN-Generierung im Onlinebanking. Die gesetzlich erforderliche Abkehr von den TAN-Listen haben viele Banken diesen Weg gehen lassen. Die bis dahin Verwendung findenden SMS ließen sich auch mit einem normalen Handy empfangen, die Apps setzten bereits ein iOS oder Google Android voraus. Diesem Prinzip folgen nun immer mehr Anbieter. DHL möchte demnächst Packstationen nutzen, die nur noch per App funktionieren, die SMS-Codes hat man bereits abgeschaltet. Krankenkassen setzen zur Abwicklung von Kundenkontakten auf eine App über die man Dokumente und Nachweise fotografiert und übertragt. In diesem Frühjahr hat sich der Staat eingereiht und bietet die Corona Tracing App nur für proprietäre iOS und Android-Systeme. Die Liste lässt sich nahezu unendlich fortführen, so funktioniert beispielsweise die Inbetriebnahme von Sonos Lautsprechern über eine App, der bequeme Online Check-in der DB setzt die Nutzung des DB Navigators voraus usw. usf.

Zu diesen ganzen Diensten kommen noch die eigenen Angebote von Apple und Google. Die mobilen Bezahldienste beider Anbieter übertragen gewissermaßen das Betriebssystem-Duopol in den Mobile Payment-Bereich. Weitere Angebote lassen sicher nicht lange auf sich warten.

Natürlich mag man jetzt bei einigen Sachen wie beispielsweise den Sonos Lautsprechern oder der DHL Packstation argumentieren, dass dies verzichtbarer Luxus ist. Aber Onlinebanking oder Kontakt zur Krankenkasse auch? Die Alternative lautet hier Briefverkehr oder Schalter (sofern es noch eine Bankfiliale gibt) und bedeutet doch erhebliche Einschränkung. Bei der Corona App gibt es schlicht gar keine Alternative mehr.

Es spricht viel für die Fortsetzung dieses Trends in der Zukunft.

Dem Anwender bleibt nur noch die digitale Abstinenz oder die Akzeptanz des gegenwärtigen Zustands und zumindest zeitweisen Benutzung eines solchen Geräts. Ein Stückweit verliert jeder dadurch die Hoheit über die Frage welche Geräte er selbst benutzen möchte und welche Betriebssysteme darauf laufen sollen.


Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

"

Im März stellte ich die Frage ob Custom ROMs generell in der Krise sind (siehe: Custom ROMs in der Krise?). Während das Problem grundsätzlich nicht von der Hand zu weisen ist, darf man aber die regionale Fragmentierung des Android-Markts nicht unterschätzen.

Der Android Markt ist allgemein extrem unübersichtlich. Es gibt nicht die Top 10 der Android Modelle für die gesamte Welt. Das fängt schon bei den vielen Sondermodellen für bestimmte Weltregionen an und bei den zahlreichen Rebranding-Maßnahmen. Das Vorjahresmodell wird dann mit leichten Modifikationen zum "Lite" Modell diesen Jahres etc. pp.

Hinzu kommen regional extrem unterschiedlich ausgeprägte Präferenzen für Hersteller. Abgesehen von Samsung ist kaum ein Anbieter von Android Smartphones auf der ganzen Welt erfolgreich. Schaut man sich den deutschen Markt an, so bestimmen neben Samsung vor allem Huawei und Xiaomi das Bild. Danach kommen weitere Hersteller aus China wie Oppo, OnePlus und aus alter Verbundenheit spielen Smartphones unter dem Nokia-Branding ebenfalls noch eine Rolle. Viele Mobilfunkanbieter listen zudem noch das Fairphone.

Ganz anders sieht das in Märkten wie den USA aus. Dies beginnt schon bei der Verteilung zwischen Android und iOS. Im Gegensatz zu vielen anderen Regionen der Welt teilen sich beide Betriebssysteme den Markt jeweils circa zur Hälfte. Huawei und Xiaomi spielen im Android Segment nahezu keine Rolle, was sicherlich auch an der restriktiven US-Politik gegen Huawei liegen dürfte. Relevanz hat hingegen LG, das hierzulande massiv an Boden verloren hat und die Lenovo-Tochter Motorola, die formell immer noch in den USA beheimatet ist.

Das ist auch der Grund weshalb die Situation bei Custom ROMs für Huawei sehr schlecht aussieht. Denn die Community Entwickler kommen größtenteils nicht aus Deutschland und oft nicht mal aus Europa. Custom ROMs werden für verfügbare Geräte erstellt, meistens für solche, die man selbst besitzt. Hat Huawei oder Xiaomi keine Absätze sieht es auf XDA-Developers meist schlecht aus. Dementsprechend schlecht sieht es für Kunden aus Deutschland aus.


Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

"

11. Juli 2020

Große Open Source Projekte kämpfen zunehmend mit Finanzierungsschwierigkeiten bei der Entwicklung. Mehrere Projekte begegnen dem nun mit Einschränkungen bei der Open Source Freigabe. Das könnte erst der Anfang gewesen sein.

Begonnen hat es mit Software wie Redis oder MongoDB. Ende letzten Jahres kündigte dann der Hersteller der Monitoring-Lösung Sentry den Wechsel auf eine unfreie Lizenz an. Anfang des Jahres dann der Paukenschlag. Waren bis dahin primär Spezialsoftware im Server/Cloud-Bereich betroffen rückten die Ereignisse nun in Richtung Desktop/Anwender vor. Die Qt Company gab bekannt künftig LTS Versionen nur noch für zahlende Kunden zur Verfügung zu stellen.

Der nächste in der Reihe ist nun LibreOffice. In einem ersten Schritt möchte man zwar lediglich mit dem Zusatz "Personal Edition" den privaten Gebrauch der frei verteilten Lösung hervorheben aber jedem dürfte klar sein wo die Reise hingehen kann. Wenn sich die Entwicklung bei Supportverträgen und Rentabilität für die maßgeblichen Firmen wie z. B. Collabora nicht bald verbessert, dürften diese entweder die Arbeit einstellen oder versuchen eine "Professional Edition" mit zusätzlichen Funktionen zu verkaufen. Bisher bot man ja lediglich einen verbesserten Support und längere Unterstützung, verfolgte also das klassische Service-Modell.

Dieses Modell klappt in ein paar Bereichen ganz gut, wo Serviceverträge üblich und Zertifizierungen unumgänglich sind. Die Masse der Projekte bewegt sich aber in anderen Bereichen. Ich habe über dieses Thema vor rund einem halben Jahr schon mal einen Blog-Artikel verfasst (siehe: Reflexionen: Open Source hat kein funktionierendes Monetarisierungsmodell). Das Feedback in den Kommentaren war in Summe ziemlich ablehnend. Diese Ignoranz ist Teil des Problems. Es darf einfach nicht wahr sein, was nicht wahr sein soll.

Die breite Masse der Anwender - privat und professionell - betrachtet Open Source eben doch einfach als "frei wie in Freibier" um ein altes Sprichwort zu zitieren.

Die Entwicklung wird noch schlimmer werden. Wer trägt denn den Großteil der Last an der Desktopentwicklung? Es sind eine Handvoll Firmen mit Open Source Verbindungen. Mozilla für den Browser, Collabora für Office, Red Hat für GNOME und relevante Teile der Basis, sowie noch eingeschränkt bluesystems für KDE. Ohne diese Akteure gibt es kaum Entwicklung am Linux Desktop. Natürlich gibt es dazu viele Freiwillige und die leisten großartige Arbeit aber die Qualität, Schlagzahl und das Niveau der aktuellen Entwicklung lässt sich ohne bezahlte Entwickler kaum halten. Zumal das Umfeld sich immer mehr beschleunigt und immer anspruchsvoller wird. Im mobilen Bereich sieht man wie schwer es für die Community ist hier ohne Firmenrückhalt Fuß zu fassen.

Mozilla steckt schon länger in der Krise, der Marktanteil für Firefox ist extrem rückläufig, Collabora hat auch keine optimalen Perspektiven, das sieht man an der aktuellen LibreOffice-Debatte. Bei den Distributoren hat sich SUSE bereits weitestgehend zurück gezogen und Red Hat wurde von IBM erworben. Hier wird bald härter gerechnet werden. Die nachlassende Qualität bei CentOS (siehe: CentOS mit unklarem Supportstatus) kann als deutliches Signal hin zu einer Stärkung von RHEL gedeutet werden.

Früher haben Firmen für Open Source nebenbei mit entwickelt. Aus Verbundenheit, für den internen Gebrauch und aus vielen weiteren Motiven. Früher hatte Novell/SUSE Mitarbeiter, die an OpenOffice schrieben, Sun entwickelte parallel wirtschaftliche und unwirtschaftliche Projekte, Red Hat machte Gewinn am Servermarkt und investierte in den Linux Desktop. Diese Zeiten enden! Entweder sind die Akteure vom Markt verschwunden, aufgekauft worden oder es sind börsennotierte Unternehmen. Dauerhafte Quersubventionen zwischen Abteilungen gibt es im 21. Jahrhundert nicht mehr. Die Zerschlagung der Großkonzerne zeigt das im Großen, aber es ist im Kleinen kaum anders.

Man muss der Wahrheit ins Gesicht sehen. So wie es aktuell läuft geht es nicht weiter. Jedenfalls nicht auf dem aktuellen Niveau mit professionell angestellten Entwicklern in unrentablen Bereichen. Weil Open Source in der Wahrnehmung eben doch wie Freibier ist.


Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay  

"

10. Juli 2020

Große Bildschrime mit 4K-Auflösung haben ihren Reiz. Das betrachten von Bildern ist viel angenehmer, genau wie deren Bearbeitung. Mehr Pixel bedeuten auch mehr Platz, man kann viele Fenster gleichzeitig geöffnet haben, ohne dass sich die Fenster überdecken.

Es gibt aber auch einen entscheidenden Nachteil: Die auf Pixelanzahl basierenden Schriftarten werden plötzlich sehr klein! Diesen Effekt unterschätzt man gerne, weil man ja denkt: größerer Bildschirm entspricht größerer Schrift! Das ist zwar sehr häufig der Fall, aber nicht bei allen Anwendungen.

Fenster werden größer, Schriften werden kleiner

In den Windows-Anzeigeeinstellungen kann man für das gesamte System die Skalierung einstellen. Auf manchen Laptops mit hochauflösenden Displays ist häufig 150% oder gar 200% eingestellt. Bei machen Anwendungen fühlt es sich daraufhin an, als ob man regelrecht angebrüllt wird. Daher lasse ich die Voreinstellung auf meinem stationären PC bei 100% Vergrößerung und kümmere mich um das einzige Programm, bei dem ich ernsthaft Schwierigkeiten habe: Thunderbird.

Schriftgröße auch für Posteingang und Ordner vergrößern

Die eingebaute Vergrößerung für Thunderbird (Menü, Ansicht, Zoom), Strg + „Plus“ bzw. Strg + „Minus“ funktioniert schonmal. Allerdings wird damit ausschließlich der Nachrichteninhalt vergrößert. Der Posteingang und die Ordner bleiben weiterhin in der kleinen Schriftart.

Abhilfe versprechen Plugins, die sind aber heute (Stand: Juli 2020) nicht mehr mit der aktuellen Thunderbird-Version kompatibel (68.9.0). Zum Glück braucht man aber auch gar kein Addon oder Plugin, um die Schriftart zu vergrößern.

Konfiguration anpassen, kein Addon installieren

Im Experten-Einstellungsmenü findet man die notwendige Einstellung. Man navigiere folgendermaßen:

  • Thunderbird-Menü
  • Einstellungen >
  • Einstellungen
  • Erweitert
  • Allgemein
  • Konfiguration bearbeiten… (das entspricht dem about:config)
    ggf. muss man mit „Ich bin mir der Gefahren bewusst!“ bestätigen.

Dort findet man den Parameter layout.css.devPixelsPerPx, der ist standardmäßig auf -1.0 eingestellt. Diesen Parameter muss man entsprechend anpassen, ich habe mich für 1.2 entschieden, dadurch erhalte ich eine angenehme Vergrößerung aller Schriften in Thunderbird.

Schriftgrößenvergleich in Thunderbird

The post Thunderbird: Schriftgröße verändern ohne Addon first appeared on bejonet - Linux | Smart Home | Technik.

9. Juli 2020

Mozilla hat mit Firefox 78.0.2 für Windows, Apple macOS und Linux ein Sicherheits- und Fehlerbehebungs-Update veröffentlicht.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Mozilla hat Firefox 78.0.2 veröffentlicht und behebt damit eine als moderat eingestufte Sicherheitslücke, welche es ermöglichte, den X-Frame-Options-Header einer Website zu umgehen.

Außerdem hat Mozilla einen Fehler behoben, der dafür sorgte, dass die Adressleiste nicht benutzbar war, wenn eine von der Adressleiste verwendete Datenbank wie die places.sqlite, welche die Lesezeichen und Chronik beinhaltet, einen Defekt hatte.

Weiter wurde ein Fehler beim Öffnen bestimmter externer Anwendungen behoben, sowie ein Barrierefreiheits-Problem in der Leseansicht.

Der Beitrag Mozilla veröffentlicht Sicherheits-Update Firefox 78.0.2 erschien zuerst auf soeren-hentzschel.at.

8. Juli 2020

Mit Firefox Send bietet Mozilla einen kostenlosen und die Privatsphäre respektierenden Filesharing-Dienst an. Nun hat Mozilla diesen vom Netz genommen. Firefox Send soll allerdings wiederkommen.

Firefox Send ist ein Filesharing-Dienst, den Mozilla im März 2019 offiziell gestartet hat. Die Nutzung von Firefox Send ist kostenlos und erfolgt durch eine Ende-zu-Ende-Verschlüsselung sicher. Durch die Festlegung einer Maximal-Dauer sowie einer Maximal-Anzahl an Downloads löschen sich die Dateien nach kurzer Zeit wieder von selbst vom Mozilla-Server.

Wer die Website von Firefox Send aufruft, wird seit heute allerdings von einer Meldung begrüßt, welche darauf hinweist, dass Firefox Send derzeit nicht zur Verfügung steht, während Mozilla an Produktverbesserungen arbeite. Auch eigentlich noch gültige Download-Links funktionieren nicht mehr.

Firefox Send ist derzeit offline

Wie die Kollegen von ZDNet.de berichten, hat Mozilla seinen Filesharing-Dienst offline genommen, weil Firefox Send zunehmend dazu verwendet worden sei, „Nutzlasten für alle Arten von Cyberkriminalität zu speichern, von Lösegeld- bis hin zu Finanzkriminalität und von Banking-Trojanern bis hin zu Spyware, die gegen Menschenrechtsaktivisten eingesetzt wird“. In einem Interview mit ZDNet.de beschrieb Cybersicherheitsforscher Colin Hardy als Problem, dass Firefox-URLs von Natur aus vertrauenswürdig seien, weswegen Spam-Filter nicht ansprängen, außerdem sorge die Verschlüsselung aller Dateien, welche dem Schutz der Dateien dienen soll, gleichzeitig dafür, dass die Erkennung von Malware erschwert wird. Durch den automatischen Ablauf wäre außerdem die Reaktion auf Vorfälle schwierig.

Mozilla nimmt dieses Problem sehr ernst. Statt Versprechungen zu machen, während der Dienst normal weiterläuft, hat Mozilla die Notbremse gezogen und Firefox Send komplett offline genommen. Firefox Send soll so lange offline bleiben, wie Mozilla Zeit benötigt, um diverse Verbesserungen zu implementieren.

Wie das komplette Maßnahmen-Paket aussehen wird, ist noch nicht bekannt. Zu zwei Änderungen gibt es aber bereits Informationen: Nach dem Neustart von Firefox Send wird es nicht länger möglich sein, Firefox Send ohne Firefox-Konto zum Versenden von Dateien zu nutzen. Außerdem wird Mozilla einen Mechanismus zum Melden von Missbrauch integrieren. Wann Firefox Send wieder online gehen wird, steht zu diesem Zeitpunkt noch nicht fest.

Der Beitrag Mozillas nimmt Filesharing-Dienst Firefox Send vorübergehend offline erschien zuerst auf soeren-hentzschel.at.

6. Juli 2020

Nach der Einführung in Red Hat Insights und dem Blick auf den Advisor nehme ich in diesem Artikel das Schwachstellen-Management von Insights unter die Lupe.

shows-rh-insights-dashboard
Bild 1: Übersicht im Insights Dashboard

Bereits das Dasboard zeigt eine Box namens Vulnerability. Bild 1 zeigt, dass wir offensichtlich von 13 Schwachstellen betroffen sind. Diese sehen wir uns jetzt näher an. Dies geht wie üblich über den Link in der Box oder im Menü am linken Rand.

In der Vulnerability-Ansicht erwartet uns die gewohnte tabellarische Ansicht (vgl. Bild 2). Hier werden CVEs mit ihrer ID, dem Datum der Veröffentlichung, einer Bewertung des Impacts, dem CVSS base score und der Anzahl der betroffenen Systeme aufgeführt. Darüber hinaus hat man die Möglichkeit ein Business Risk und einen Status für ausgewählte oder alle CVEs zu vergeben (siehe gelbe Markierung in Bild 2).

rh-insights-vulnerability-view
Bild 2: Übersicht gefundener Schwachstellen mit Angabe von Impact, CVSS score und betroffener Systeme

Während man mit dem Business Risk festlegt, wie hoch man das Risiko einschätzt (vgl. Bild 3), hinterlegt man beim Status, wie mit der Behandlung der Schwachstelle(n) verfahren wird (siehe Bild 4).

edit-vulnerability-business-risk
Bild 3: Bewertung des Business Risk
rh-insights-edit-vulnerability-status
Bild 4: Mit Hilfe des Status kann der Bearbeitungsstand dokumentiert werden.

Wie im Advisor erhält man auch hier zu jeder CVE-ID eine Detailansicht mit Beschreibung des CVE, Bewertung und Übersicht der Angriffsvektoren (siehe Bild 5), sowie Verweisen zur Wissensdatenbank von Red Hat, wo ausführliche Informationen rund um den CVE und existierende Erratas zu finden sind.

rh-insights-cve-view-details
Bild 5: Detailansicht eines ausgewählten CVE

Bewertung des Schwachstellen-Managements

Stand heute betreiben wir kein aktives Schwachstellen-Management. Um ein gewisses Niveau an Sicherheit zu gewährleisten, nutzen wir ein Patchmanagement für RHEL, welches ich aus Bordmitteln unter Nutzung der Ansible Engine entwickelt habe. Dieses sorgt dafür, dass verfügbare Red Hat Security Advisories einmal im Monat auf allen RHEL-Systemen zwangsinstalliert werden, sofern diese noch fehlen.

Diesem Patch-Management ist es zu verdanken, dass auf den 13 angebundenen Testsystemen auch insgesamt nur 13 Schwachstellen gefunden wurden und darunter keine mit einem Score >= 8 gewesen ist.

Unter den im Dashboard aufgeführten Systemen waren Systeme einer Testinfrastruktur, die nicht an das zentrale Patchmanagement angebunden sind und nur unregelmäßig gepatcht werden. Insights hat mir hier vor Augen geführt, dass das Risiko viel zu groß ist, dass diese Systeme einfach vergessen werden. Deshalb wurden diese Hosts nun auch umgehend mit ins Patchmanagement aufgenommen.

Deutlich interessanter finde ich, dass mich Insights auf die CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 und CVE-2019-11091 aufmerksam gemacht hat.

Diese Schwachstellen haben gemeinsam, dass sie sich nicht einfach durch die Installation eines Updates schließen lassen. Da es sich um virtuelle Maschinen (VM) auf einem vSphere-Cluster handelt ist eine Kombination von Maßnahmen erforderlich, um die Schwachstellen zu mitigieren.

In diesem konkreten Fall müssen die betroffenen VMs lediglich einmal Aus- und wieder Eingeschaltet werden, da ein Teil der Mitigation in vSphere bereits vorhanden war. Dadurch werden neue CPU-Funktionen an das Gast-Betriebssystem propagiert und die Mitigation ist abgeschlossen.

Leider muss ich eingestehen, dass diese Schwachstellen ohne Insights noch lange Zeit unentdeckt geblieben wären.

Nun muss ich davon ausgehen, dass in unserer Umgebung noch weitere verwundbare Systeme existieren. Da ich diese nicht an Insights anbinden darf, werde ich diese mit einem von Red Hat bereitgestellten Skript ausfindig machen. Das Red Hat eben solche Skripte zur Verfügung stellt, um sich auch ohne Insights wirksam selbst helfen zu können, schätze ich an Red Hat sehr. Es gibt da draußen noch einige Unternehmen, die diesem Beispiel ruhig folgen dürfen.

Persönlich halte ich aktives Schwachstellen-Management für sinnvoll. Nur durch kontinuierliche Kontrolle können Schwachstellen gefunden, bewertet und entsprechend behandelt werden. Gleichzeitig dient es der Überprüfung, ob bzw. wie bereits getroffene Maßnahmen zur strukturellen Verbesserung des Sicherheits-Niveaus (z.B. ein Patchmanagement) wirken.

Bild 6: Alle erkannten Schwachstellen wurden geschlossen

Bild 6 zeigt, dass gegenwärtig keine offenen Schwachstellen mehr existieren. Dies sollte stets das Ziel sein.

Mir selbst hat der Test des Schwachstellen-Managements Freude bereitet und die gefundenen Schwachstellen konnten innerhalb kurzer Zeit geschlossen werden.

Der nächste Artikel dieser Reihe wird sich dem Compliance-Service widmen.

4. Juli 2020

Joomla steckt(e) in gehörigen Schwierigkeiten und die kommende Version 4 verzögerte sich immer mehr. Nun ist auf Beta 1 binnen eines Monats schon Beta 2 gefolgt und in ersten Tests wirkt die Version schon weit vorangeschritten. Eine finale Version gegen Jahresende rückt damit wieder in den Bereich des möglichen.

Webentwicklungen kommentiere ich normalerweise nicht, aber Joomla ist die technische Grundlage dieser Seite und damit tangieren mich die Probleme des Projekts direkt (siehe: Joomla in Schwierigkeiten?). Schließlich ist es alles andere als attraktiv eine Seite mit an die tausend Artikel auf eine andere Plattform zu migrieren.

Die Funktonen und Änderungen der neuen Hauptversion lesen sich vielversprechend:

  • Joomla im Handumdrehen installieren: Einfacher, schneller und benutzerfreundlicher Installationsprozess
  • Brandneue Benutzeroberflächen (Backend und Frontend): intuitiv und logisch, leicht verständlich und benutzerfreundlich
  • Joomla stellt Menschen an erste Stelle: Wir wollen sicherstellen, dass die Templates barrierefrei zugänglich sind (Stufe AA der WCAG 2.1)
  • Ein vollständig überarbeiteter Media Manager: Mit einer klaren und logischen Benutzerschnittstelle und eingebauten Bildbearbeitungsoptionen
  • Ein neuer Workflow: Inhalte auf eine erweiterte und anpassbare Weise verwalten
  • Webservices: Inhalte sind für andere Websites oder mobile Anwendungen zugänglich.
  • Neue Sicherheitsfunktionen: bspw. neue Funktionen wie die Unterstützung für vorbereitete SQL-Anweisungen
  • HTML-Mail-Vorlagen: Noch nie war es so einfach, angepasste E-Mails von Ihrer Website aus zu versenden!
  • Verbesserte und erweiterte Befehlszeilenschnittstelle (CLI): Für eine reibungslose Integration der Komponenten
  • Eine sauberere und leistungsfähigere Codebasis: Der Code wurde gründlich bereinigt, alle veralteten Funktionen von Joomla 3.x wurden entfernt, und PHP-Namespaces wurden eingeführt, wodurch Entwickler robustere und innovativere Anwendungen als je zuvor bereitstellen können.
  • Die Leistungsfähigkeit des Joomla-Frameworks verschmolz mit dem CMS.
  • Ein verbessertes Ereignis-Dispatching-System
  • Und noch vieles mehr!

Vor allem auf das neue Backend-Template und den neuen Media Manager freue ich mich. Hier ist Wordpress der Konkurrenz weit voraus. Allerdings finde ich die technische Monokultur im Netz besorgniserregend. Die große Mehrheit der Seiten hängt an Wordpress und damit auch an Automattic. Daneben spielen nur noch Drupal und Joomla eine nennenswerte Rolle. Umso schöner zu sehen, dass letztere nun wieder in die Spur gefunden haben.


Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

Android 11 steht quasi in den Startlöchern und wie immer geht für Android-Nutzer die bange Frage los welche Geräte wohl ein Update bekommen. Dabei zeigt sich einmal mehr, dass auch Googles Pixel Serie hier nur begrenzte Zeiträume anbieten und nichts mit Apple mithalten kann.

Wenn man über Android und die ewige Updateproblematik schreibt kommen zuverlässig Kommentatoren, die darauf hinweisen, dass Hersteller xyz es besser macht. Oft ist dies angeblich Google selber mit seiner Pixel-Serie.

Die aktuelle Updateliste zeigt, dass dem nur bedingt so ist. Das Pixel der 1. Generation von 2016 ist aus dem Support gefallen und erhält kein Android 11 mehr. Die Pixel-Reihe führte trotzdem hier noch die Android-Riege an. Bei Samsung wird es den Gerüchten nach Android 11 nur noch für S10 und neuer geben. Bei Huawei liegt die Grenze wohl beim P30. Alles Modelle aus dem Jahr 2019 womit sich die durchschnittliche Supportdauer von 2 Jahren für Android Smartphones bestätigt. Zum Vergleich. Das iPhone 6s aus dem September 2015 wird nach vorliegenden Informationen noch das Update auf iOS 14 im Herbst 2020 bekommen.

Während der wirtschaftliche Sinne hinter der Strategie von Samsung oder Huawei offensichtlich ist, verstehe ich die Updatepolitik von Google nicht. Die Pixel-Sparte ist eher Prestige-, denn Umsatzbringer und letztlich interessiert sich Google primär für die Daten der Anwender. Ist Android wirklich so ein mieses Betriebssystem, dass es auf einem 4 Jahre alten Prozessor wie dem Snapdragon 821 nicht mehr läuft?

Es gibt keine belastbaren Daten wie lange die Deutschen ihre Smartphones nutzen. Es gibt aber Hinweise darauf, dass Smartphones länger genutzt werden, als noch vor wenigen Jahren. Schaue ich mich in meiner Umgebung um, so sehe ich sehr viele ältere und alte Modelle. Ein Indikator ist hier ja meist schon das fehlende Fullscreen-Display. Das macht auch Sinn, da die Entwicklung nicht mehr so rasant verläuft wie vor 5 Jahren und Smartphones technisch deutlich langsamer veralten. Ich halte daher die Nerdblase mit einer Smartphone-Lebensdauer von 12-24 Monate für nicht repräsentativ. Im Zuge der Corona App-Diskussion kam der hohe Anteil an veralteten Betriebssystemen schließlich ebenfalls zur Sprache.

Allerdings ist es den meisten Anwendern wohl egal, ob ihr Smartphone noch Updates bekommt oder nicht. Das Problembewusstsein ist anders als beim Desktop oder Notebook noch nicht sonderlich verbreitet.

Nachhaltiger und auf die Jahre vermutlich sogar preiswerter sind iPhones. Eine Ironie wenn man bedenkt, dass Linux und freie Software auf dem Desktop exakt für das Gegenteil steht: Langlebigkeit und Ressourcensparsamkeit.


Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay 

"

Am 02. Juli veröffentlichte das openSUSE Projekt eine neue Version des LTS-Zweigs Leap. Als Minor-Veröffentlichung im Hauptzweig 15 erwartet den Anwender vor allem solide Produktpflege. Eine wesentliche Neuerung hat man gut versteckt: Native Btrfs Verschlüsselung. Die Zukunft bringt zudem noch mehr Enterprise-Niveau.

Ähnlich wie bei Ubuntu 20.04 (siehe: Kein Ubuntu 20.04 Test) beabsichtigte ich eigentlich den obligatorischen Testbericht dieses Jahr ausfallen zu lassen. OpenSUSE ist ein tolles Projekt und Leap ein totaler Erfolg. Es ist eine super stabile Basis um damit Desktops, Notebooks oder Heimserver zu betreiben. Minorversionen bringen aber nur Produktpflege. Der Desktop zieht auf eine neue LTS-Variante, ausnahmsweise gab es auch einen neuen Kernel. Aber alle das rechtfertigt einfach keinen intensiven Test. Vermutlich hätte man einfach den Bericht des letzten Jahres (siehe: openSUSE Leap 15.1 im Test) nehmen können und lediglich die Versionsnummern austauschen müssen. Das hätte zwar Klicks generiert (und so arbeiten leider viele Blogger) aber wäre für alle treuen Leser doch ziemlich langweilig gewesen

Darum gibt es keinen Testbericht aber die ernst gemeinte Empfehlung openSUSE Leap in Betracht zu ziehen, wenn man eine solide LTS-Distribution sucht.

Zwei Entwicklungen verdienen dennoch eine dezidierte Meldung:

1. Verschlüsselung

Verschlüsselung funktioniert bei allen Linux-Varianten und nahezu allen Dateisystemen ziemlich ähnlich (siehe: LUKS - Betriebssystem verschlüsseln). Man erzeugt ein verschlüsseltes logisches Volume (LVM) und richtet in diesem die obligatorischen Partitionen für das System, Home und ggf. andere Bereiche ein. Daneben gibt es zwar noch andere Möglichkeiten wie die von Google entworfene native ext4 Verschlüsselung oder ZFS-Verschlüsselung aber das ist nie wirklich auf dem Linux Desktop angekommen.

OpenSUSE bietet hier nun Möglichkeiten ohne LVM-Container an. Bisher war eine Verschlüsselung in der Installationsroutine nur mittels LVM möglich. Nun funktioniert es auch ohne und in Kombination mit Btrfs wohl auch Festplatten-übergreifende Lösungen. Das konnte ich allerdings mangels geeigneter Hardware nicht testen. Die Lösung ohne Container klappt aber bereits sehr gut.

Zuerst startet man eine neue geführte Partionierung im entsprechenden Schritt während der Installationsroutine.

Um doppelte Passwortabfragen beim Starten zu verhindern sollte man in Erwägung ziehen eine unverschlüsselte Boot-Partition anzulegen, sowie den Benutzer automatisch einzuloggen. Beides ist aber nur ein Komforthinweis und keine Notwendigkeit.

Anschließend wählt man die verschlüsselte Partitionierung, aber keine LVM-basierte Variante.

Im anschließenden Schritt belässt man die Wahl natürlich bei Btrfs. Im Abschluss sieht man dann eine Btrfs-basierte Partitionierung ohne LVM.

Nach Installation und Neustart erfolgen mehrere Passwortabfragen weil jede Partition einzeln verschlüsselt ist. Sofern man keine unverschlüsselte Boot-Partition nutzt erfolgt bereits vor dem Start von Grub eine Abfrage. Hier sollte man bei der Eingabe das US-Layout bedenken.

Insgesamt eine interessante Entwicklung, da LVM in Kombination mit Btrfs eigentlich überflüssig ist.

2. Closing the Leap Gap

OpenSUSE Leap und SUSE Linux Enterprise teilen bereits eine gemeinsame Basis. Momentan geschieht dies auf Basis des Quellcodes der SLE-Pakete, die Leap neu baut. Künftig will SUSE bereits die Binaries anbieten somit die Kompatibilität zwischen SLE und Leap verbessern (siehe die FAQ bei openSUSE). Im Ergebnis könnte Leap noch stabiler und "Enterprise-tauglicher" werden. Durchaus eine interessante Entwicklung angesichts des Abstiegs von CentOS (siehe: CentOS mit unklarem Supportstatus). Im Herbst könnte es deshalb eine Zwischenversion 15.2.1 geben, sofern die Entwicklung bis dahin weit genug voran geschritten ist.


Bilder:

Einleitungs- und Beitragsbild von ar130405 via Pixabay 

"

Ein Linux ohne alte Zöpfe ist eine interessante Sache. Genau eine solche Idee hat nun Ikey Doherty vorgestellt. Noch ist es nicht mehr als ein Konzept, aber es verspricht Potenzial und zeigt einige Probleme in der Desktop-Entwicklung.

Das Projekt hat Ferdinand Thommes auf Linuxnews kurz und treffend zusammen gefasst. Es soll eine Linux Distribution sein, die alle alte Zöpfe abschneidet und sich quasi symbolisch von GNU trennt.

  • Wechsel auf Clang
  • musl als libc
  • Keine Unterstützung für Legacy BIOS, sondern nur UEFI
  • Nur Wayland und keine Unterstützung für X11
  • Kompletter usr-merge.
  • Verzicht auf Blocker wie NVIDIA
  • Ggf. weitere Kompatibiltiät in Form von Containern

Wird das ein voller Erfolg oder das neue Standard-Linux? Nein ich denke nicht und das soll es vermutlich auch nicht werden. Es ist ein mutiges Vorangehen und eine Experimentalstudie, die zeigen soll was möglich ist.

Denn Linux befindet sich auf dem Desktop - in der Form wie es nahezu alle Distributionen ausliefern - in einer Kompatibilitätshölle. Graubärtige Anwender und graubärtige Entwickler (Frauen gibt es ja kaum) halten an uralten Technologien fest und blockieren jede Veränderung (siehe: Kommentar: Wenn die Anwender sich verweigern & FOSDEM: Graubärte, GPL-Probleme und Fortschritt). Natürlich gab es immer Distributionen wie Debian, die konservativ waren und darin sicher auch ihre Daseinsberechtigung hatten, aber inzwischen sind alle Distributionen konservativ. Wann ist das letzte Mal eine Distribution mutig voran gegangen wie Ubuntu als es PulseAudio einsetzte? Damals gab es viel Kritik aber nur der breite Einsatz hat die Software wirklich alltagstauglich gemacht und heute nutzt das quasi jede Distribution.

Ein gutes Beispiel dafür ist Wayland, das seit über 10 Jahren in der Entwicklung ist und immer als Zukunft von Linux angesehen wird. Eine Zukunft, die nie kommt weil alle nennenswerten Distributionen standardmäßig aus Kompatibilitätsgründen an X11 festhalten und die Treiberentwickler und Desktopentwickler deshalb auch kaum einen Grund haben ihre Projekte Wayland-ready zu bekommen. Die Katze beißt sich hier in den eigenen Schwanz.

Umso schöner ist es wenn nun einzelne Entwickler experimentell voran gehen und zeigen wo es hingehen kann. Nicht alles davon wird funktionieren aber hoffentlich einiges im Mainstream-Bereich ankommen.


Bilder:
Einleitungsbild und Beitragsbild von von 200 Degrees via pixabay

"

3. Juli 2020

Leider gehört ein Widget zur CPU und Energiesteuerung nicht zur Standardinstallation bei Kubuntu. Aber glücklicherweise gibt es einen recht einfachen Weg, um ein sehr schickes Widget verfügbar zu machen.

Das Widget heisst plasma-pstate und ist zu finden auf https://github.com/jsalatas/plasma-pstate und die Installation ist recht einfach beschrieben auf der Seite.

 

Für Kubuntu 20.04 habe ich Folgendes gemacht

sudo apt install linux-tools-generic linux-tools-`uname -r`

cd Download
mkdir CPUfreqWidget
cd CPUfreqWidget
git clone https://github.com/jsalatas/plasma-pstate
cd plasma-pstate
sudo ./install.sh

Und anschließend auf die Arbeitsoberfläche klicken “Miniprogramme hinzufügen…” und das Widget “Intel P State and CPUFreq” in die Statusleiste hinzufügen. Und schon hat man ein tolles Menü, in dem man die Leistung des Computers manuell beeinflussen kann.
Screenshots des Widgets findet ihr auf der github Seite in der Beschreibung.

 

 

2. Juli 2020

Mozilla hat mit Firefox 78.0.1 für Windows, Apple macOS und Linux ein schnelles Update für Firefox 78 veröffentlicht.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Mit einem schnellen Update auf Firefox 78.0.1 behebt Mozilla ein mit Firefox 78 eingeführtes Problem, welches beim Update von einer älteren Firefox-Version verursachen konnte, dass die Suchmaschinen nicht verfügbar waren. Dies ist die einzige Änderung gegenüber Firefox 78.

Der Beitrag Mozilla veröffentlicht Firefox 78.0.1 erschien zuerst auf soeren-hentzschel.at.

In meinem letzten Artikel habe ich erklärt, wie man unter Linux die Firewall mit einem IP Block ausstatten kann.
In diesem Artikel möchte ich euch erklären, wie ihr auch IP’s melden könnt, und somit der Community wieder was zurückgeben könnt.

Fail2Ban installieren

Fail2Ban ist schnell installiert:

1
apt install -y fail2ban

Fail2Ban und UFW

Wie im ersten Artikel bereits beschrieben, nutze ich als Firewall für meine Systeme UFW. Damit Fail2Ban mit UFW sprechen kann, müssen wir kleine Anpassung machen.
Als Erstes müssen wir die Datei jail.local erstellen, dazu macht einfach folgendes:

1
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

In der jail.local such jetzt bitte die folgende Zeile (ist bei mir die 167):

1
banaction = ....

Alles hinter dem Gleichzeichen entfernen und ufw angeben.

Fail2Ban und AbuseIPDB

Als Nächstes müssen wir in der jail.local noch eine Änderung vornehmen.
Sucht in der Datei, im [DEFAULT] Block bitte die folgende Zeile (ist bei mir 228 kurz vor dem sshd Jail):

1
action = %(action_)s

Diese muss durch die folgende erstes werden, passt auch direkt deine API Key an.

1
2
action = %(action_)s
%(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18"]

Was haben wir gerade gemacht?
Wir haben Fail2Ban gesagt, dass er bei einem Ban, die IP die gebannt wird, an die Aktion AbuseIPDB (bearbeiten wir gleich) übergeben werden soll, mit der Kategorie 18 (Brute-Force).
Weiteres zu den Kategorien hier.

In diesem Teil habe ich jetzt beschrieben, wie wir allgemein eine Aktion für alle Bans aufrufen können. Natürlich kann man das für jeden Jail auch einzelnen machen, und so genauer melden, wenn man die entsprechenden Kategorien angibt.
So könnte man die Zeile oben auf Default lassen und im Jail sshd zum Beispiel das folgende machen:

1
2
3
4
5
6
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
action = %(action_)s
%(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18,22"]

Jetzt sind die Kategorien die wir melden, 18 (Brute-Force) und 22 (SSH). So kann AbuseIPDB, das viel genauer filtern und anderen zur Verfügung stellen.

Als letztes müssen wir noch die Action abuseipdb anpassen. Leider, ist die action die mit Debian mitgeliefert wird nicht mehr aktuell, und führt dazu, das ihr nichts melden könnt, weil die API falsch angesprochen wird.
Dazu geht in die Datei /etc/fail2ban/action.d/abuseipdb.conf.

Löscht die aktuelle Zeile, die mit actionban = begint komplett und setzt die folgenden rein:

1
actionban = curl --tlsv1.2 --fail 'https://api.abuseipdb.com/api/v2/report' -H 'Accept: application/json' -H 'Key: <abuseipdb_apikey>' --data-urlencode "comment=<matches>" --data-urlencode 'ip=<ip>' --data 'categories=<abuseipdversionb_category>'

WICHTIG: hier nichts einsetzen, so eintragen wie ich es hier geschrieben habe, der APIKey und die IP und die Kategorien werden von Fail2Ban bei einem Ban übergeben!

Jetzt alles speichern und einen neustart von fail2ban machen:

1
fail2ban-client restart

Hier sollte kein Fehler kommen, sicherheitshalber kann man auch nochmal die Log überprüfen:

1
cat /var/log/fail2ban.log

Ergebnis

Dementsprechend wie sehr eurer Server “angegriffen” wird, solltet ihr nach einigen Tagen bereits einige IP’s gemeldet haben, bei mir sieht das aktuell so aus:

1. Juli 2020

Mozilla hat Firefox 78 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Verbesserungen der Adressleiste

Auch in Firefox 78 hat Mozilla, wie schon in vorausgegangenen Releases, die Adressleiste weiter verbessert.

Bei Klick in die Adressleiste zeigt Firefox standardmäßig die ersten acht wichtigen Seiten an, welche auch auf dem Firefox-Startbildschirm zu finden sind. Eine neue Option in den Datenschutz-Einstellungen erlaubt es, diese Vorschläge abzuschalten. Dann erscheinen alleine durch den Klick in die Adressleiste keine Vorschläge mehr.

Firefox 78

Die Option browser.urlbar.openViewOnFocus in about:config, welche bisher von manchen Nutzern zweckentfremdet worden war, um das gleiche Resultat zu erzielen, gibt es nicht länger. Nutzer, welche diese Einstellung zuvor verwendet hatten, wurden automatisch auf die neue Einstellung migriert.

Wie viele andere Animationen der Firefox-Oberfläche ist jetzt auch die Vergrößerung der Adressleiste bei Klick in diese abhängig von der Einstellung des Betriebssytems, Animationen zu reduzieren. Aktiviert der Nutzer die entsprechende Einstellung, findet nicht länger eine Vergrößerung der Adressleiste statt.

Hat der Nutzer via Adressleiste etwas bei einer Suchmaschine gesucht und möchte anschließend nach einem ähnlichen Suchbegriff suchen, war dies in der Vergangenheit schwierig, da alles neu eingegeben werden musste. Die Adressleiste von Firefox 78 erinnert sich – standardmäßig – an die letzten zwei Suchbegriffe. Entsprechende Ergebnisse werden durch ein Uhr-Symbol gekennzeichnet. Die Anzahl kann über about:config angepasst werden, indem die Option browser.urlbar.maxHistoricalSearchSuggestions auf einen anderen Wert gesetzt wird. Ein Wert von 0 deaktiviert das Feature.

Firefox 78

Gibt der Benutzer einen Suchbegriff in die Adressleiste ein, der offensichtlich keine Domain ist, führt Firefox eine Suche bei der eingestellten Standard-Suchmaschine durch. Durch zusätzliche Eingabe von „/“ am Ende kann nun erzwungen werden, eine Domain-Auflösung zu versuchen (Firefox ergänzt standardmäßig www. und .com) statt nach dem Begriff zu suchen.

Verbesserungen im Umgang mit PDF-Dateien

Mozilla hat in Firefox 78 diverse Verbesserungen im Umgang mit PDF-Dateien implementiert.

Auf Windows ist es nun möglich, Firefox zum Standard-Programm für PDF-Dateien festzulegen.

Beinhaltet eine PDF-Datei Features, welche von Mozillas PDF-Betrachter nicht unterstützt werden, hat Firefox bereits in der Vergangenheit einen entsprechenden Hinweis mit der Option angezeigt, das Standard-PDF-Programm zu verwenden. Ist dieses Microsoft Edge, öffnet Firefox ab sofort eine reduzierte PDF-Oberfläche von Edge und nicht mehr den vollständigen Edge-Browser. Wer das nicht mag, kann das alte Verhalten über about:config aktivieren, indem der Schalter browser.pdf.launchDefaultEdgeAsApp auf false gesetzt wird.

Ist die Option ausgewählt, PDF-Dateien in Firefox zu öffnen, wurden PDF-Dateien, welche seitens Website mit application/octet-stream als Content-Type-Header gesendet worden sind, bisher heruntergeladen. Ab sofort zeigt Firefox diese PDF-Dateien auch direkt im Browser an. Wer das nicht möchte, kann das alte Verhalten über about:config wiederherstellen, indem die Option pdfjs.handleOctetStream auf false gesetzt wird.

Die Standard-Option für PDF-Dateien mit Content-Disposition: attachment-Header ist jetzt das Öffnen in Firefox. Diese Änderung kann via browser.helperApps.showOpenOptionForPdfJS auf false rückgängig gemacht werden.

Wurde eine PDF-Datei heruntergeladen, hat Firefox bisher das PDF-Programm des Betriebssystems aufgerufen, wenn die PDF-Datei im Downloads-Panel angeklickt worden ist. Ab sofort öffnet Firefox die PDF-Datei in Firefox.

Neues Design für Leseansicht

Per Klick auf das Buch-Symbol in der Adressleiste erscheinen Artikel im Web so aufbereitet, dass sie störungsfrei gelesen werden können. Konkret bedeutet dies eine angenehme Farbgebung und Schriftgestaltung sowie keine störenden Elemente wie Werbung. In Firefox 78 hat Mozilla das Design der Leseansicht modernisiert.

Firefox 78

WebRender für weitere Nutzer

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

In Firefox 78 hat Mozilla WebRender für weitere Intel-GPUs und Bildschirmauflösungen auf Windows 10 aktiviert. Außerdem kann WebRender jetzt auch auf Systemen mit Windows 7 und Windows 8 aktiviert werden – standardmäßig bleibt WebRender auf diesen Windows-Versionen vorerst allerdings noch deaktiviert. Auf Bildschirmen mit einer Bildwiederholfrequenz größer als 60 Hz wird WebRender ab sofort allerdings nicht mehr ausgeführt, da hierfür weitere Optimierungen notwendig sind, um das performant zu unterstützen.

Verbesserungen der Entwickler-Werkzeuge

Firefox zeigt an, wieso Ressourcen blockiert werden

Wenn Firefox bestimmte Ressourcen einer Website nicht lädt, zum Beispiel ein Bild oder Werbung, dann könnte dies daran liegen, dass eine Datei blockiert wird. Mit Firefox 78 hat Mozilla seinen Browser um die Möglichkeit erweitert, den Grund der Blockierung zu erfahren. Das kann beispielsweise der aktivierte Tracking-Schutz sein, aber auch eine Erweiterung wie Adblock Plus oder uBlock Origin. In dem Fall zeigt Firefox den Namen der Erweiterung an, welche die Blockierung verursacht.

Blockierte Ressourcen Firefox 78

Sonstige Verbesserungen der Entwicklerwerkzeuge

Im Netzwerkanalyse-Werkzeuge kann die Breite der Spalten jetzt überall und nicht nur im Tabellen-Header per Ziehen verändert werden. Das Barrierefreiheit-Werkzeug ist nicht länger als Beta gekennzeichnet.

Weitere Verbesserungen der Entwicklerwerkzeuge betreffen unter anderem den Debugger, die Fehlerausgabe in der Konsole und eine schnellere DOM-Navigation im Inspektor, insbesondere auf Seiten mit vielen CSS-Variablen. Auch das Remote-Debugging, um beispielsweise den neuen Firefox für Android via Desktop-Firefox zu debuggen, wurde verbessert. So kann die URL am Smartphone nun direkt am Desktop-Computer geändert werden und via Desktop-Firefox die Seite auch neu geladen werden.

Firefox 78

Ausführliche Informationen zu den Verbesserungen der Entwickler-Werkzeuge in Firefox 78 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Verbesserungen für Firefox-Erweiterungen

Firefox 78 beinhaltet auch wieder Verbesserungen für Firefox-Erweiterungen, darunter die Option für Erweiterungen, sich das letzte Download-Verzeichnis zu merken. Mehr Informationen gibt es im Mozilla-Blog.

Verbesserungen der Webplattform

Neue Engine für Reguläre Ausdrücke

Mozilla hat die Engine für Reguläre Ausdrücke in JavaScript erneuert. Dies verbessert nicht nur die Wartbarkeit für Mozilla, gleichzeitig bringt dies auch einige neue RegExp-Features. Mozilla hat darüber ausführlich geschrieben.

Sonstige Verbesserungen der Webplattform

Der Bildschirmschoner unterbricht nicht länger WebRTC-Anrufe, womit Firefox besser geeignet für Video-Telefonie und -Konferenzen über den Browser wird.

Firefox 78 unterstützt die CSS Pseudo-Klassen :is und :where. Ebenfalls unterstützt werden die CSS Pseudo-Klassen :read-only und :read-write ab sofort ohne Hersteller-Präfix (-moz-).

Erweitert wurde die Unterstützung der JavaScript Intl API. Die neue Intl.ListFormat API hilft bei der Internationalisierung von Auflistungen. Auch für die Formatierung von Zahlen gibt es neue Optionen.

Eine weitere praktische Ergänzung in JavaScript ist ParentNode.replaceChildren(), was Firefox mit dem Update auf Version 78 als erster Browser unterstützt.

Auch WebAssembly hat diverse Verbesserungen mit diesem Update erhalten.

Ausführliche Informationen zu Verbesserungen der Webplattform in Firefox 78 finden sich auf hacks.mozilla.org sowie in den MDN web docs.

Veraltete Sicherheits-Protokolle werden nicht länger unterstützt

Firefox 78 unterstützt nicht länger die veralteten Sicherheitsprotokolle TLS 1.0 sowie 1.1. Das Sicherheitsprotokoll TLS 1.0 ist bereits über 21 Jahre alt. TLS 1.1 bot nur geringfügige Verbesserungen gegenüber TLS 1.0. Aus Sicherheitsgründen ist daher das 2008 finalisierte TLS 1.2 oder noch besser das 2018 finalisierte TLS 1.3 zu nutzen. Ansonsten sieht der Benutzer ab Firefox 78 nur eine Fehlerseite.

Außerdem unterstützt Firefox 78 nicht länger die veralteten DHE-Chiffresuiten TLS_DHE_RSA_WITH_AES_128_CBC_SHA sowie TLS_DHE_RSA_WITH_AES_256_CBC_SHA.

Sonstige Neuerungen in Firefox 78

Der Schutzmaßnahmen-Bericht beinhaltet nun auch eine Information darüber, wie viele Datenlecks, sofern es welche gibt, auf Firefox Monitor als erledigt markiert worden sind, und ob gespeicherte Passwörter in bekannten Datenlecks offengelegt worden sind.

Firefox 78

Die Schaltfläche in der Navigations-Symbolleiste, welches nach Firefox-Updates erscheinen kann, kann ab sofort über eine Checkbox in diesem Panel deaktiviert werden.

Firefox 78

Beim Ausdruck von Dokumenten berücksichtigt Firefox nun mögliche Animationen, so dass Elemente, welche von unsichtbar zu sichtbar animiert werden, im Ausdruck nicht länger fehlen.

Hat man für eine Website Zugangsdaten gespeichert und meldet sich mit einem abweichenden Passwort an, fragt Firefox, ob man die gespeicherten Zugangsdaten entsprechend ändern möchte. Als weitere Option erscheint hier ab sofort, die gespeicherten Zugangsdaten zu entfernen.

Gibt es Probleme mit Firefox, ist es ein natürlicher Reflex, es mit einer Neuinstallation zu versuchen. Tatsächlich liegt die Ursache für viele Probleme aber im Firefox-Profil und eine Bereinigung des Firefox-Profils kann viele Probleme lösen. Daher gibt es im Deinstallationsprogramm von Firefox ab sofort die Möglichkeit, das Firefox-Profil zu bereinigen.

Weitere Verbesserungen gab es auch bei der Erkennung von Passwortfeldern für den Passwort-Manager.

Ein Teil der Animationen, welche über toolkit.cosmeticAnimations.enabled gesteuert werden, wird bereits seit Firefox 77 stattdessen über die Einstellung des Betriebssystems zur Reduzierung von Animationen berücksichtigt und nicht länger über diesen Schalter. Mit Firefox 78 folgen die restlichen Animationen, welche bisher durch diesem Schalter kontrolliert wurden. Entsprechend wurde dieser Schalter mit dem Update auf Firefox 78 entfernt.

Via X-FRAME-OPTIONS können Website-Entwickler festlegen, dass eine Seite nicht als iFrame eingebunden werden darf. Bislang hat der Nutzer in dem Fall nur eine Fehlerseite gesehen. Ab sofort gibt es hier eine zusätzliche Schaltfläche, welche es dem Nutzer erlaubt, die eingebundene Seite in einem neuen Tab zu öffnen.

Firefox 78

Bei Verwendung des dunklen Firefox-Themes auf Windows und Linux ist die Bibliothek jetzt auch dunkel.

Auf macOS gab es bei Verwendung mehrerer Bildschirme das Problem, dass ein Rechtsklick das Kontextmenü unter Umständen auf dem falschen Monitor angezeigt hat. Das Problem wurde behoben.

Bei Eingabe einer URL ohne Protokoll in die Adressleiste nimmt der Browser standardmäßig http:// an und zeigt eine Fehlerseite an, wenn unter dieser URL keine Seite erreichbar ist. Ab Firefox 78 versucht Firefox es zunächst noch mit https://, bevor Firefox eine Fehlerseite anzeigt.

Natürlich kam auch in Firefox 78 die Unterstützung weiterer Unternehmensrichtlinien dazu.

Firefox 78 bringt außerdem diverse Verbesserungen der Barrierefreiheit.

Geschlossene Sicherheitslücken

Auch in Firefox 78 hat Mozilla wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 78 daher für alle Nutzer dringend empfohlen.

Letztes Feature-Update für Apple macOS 10.9 bis 10.11

Nutzer der Mainstream-Version von Firefox auf Apple macOS 10.9 bis 10.11 werden automatisch auf Firefox ESR 78 migriert und erhalten damit mit Firefox ESR 78 ihr letztes Feature-Update. Nach einem weiteren Jahr Sicherheits-Updates durch Firefox ESR 78 ist für Nutzer von Apple macOS 10.9 bis 10.11 danach Schluss. Bereits Firefox 79 lässt sich auf diesen macOS-Versionen nicht einmal mehr starten.

Minimalanforderungen für Linux angehoben

Für Linux wurden die minimalen Systemanforderungen angehoben. Ab sofort werden GNU libc 2.17, libstdc++ 4.8.1 sowie GTK+ 3.14 oder neuer benötigt.

Alle Unterschiede zwischen Firefox 78 und Firefox ESR 78

Firefox 78 ist gleichzeitig die neue Basis für Firefox ESR, die Firefox-Version mit Langzeitunterstützung. Während Firefox 78 und Firefox ESR 78 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen. Diese Unterschiede und weitere wissenswerte Informationen für System-Administratoren wurden in einem gesonderten Artikel ausführlich behandelt.

Der Beitrag Mozilla veröffentlicht Firefox 78 – die Neuerungen erschien zuerst auf soeren-hentzschel.at.

Im folgenden Artikel möchte ich erläutern, wie ihr eure Linux Firewall (UFW) mit einer Blackliste von IP-Adressen, die durch Meldungen bereits als schadhafte IP’s (wurden zum Beispiel für Brute-Force) genutzt, erweitern könnt.

AbuseIPDB

Ich nutze für dieses Setup die Datenbank von AbuseIPDB. Damit auch ihr diese nutzen könnt, müsst ihr euch einfach einen kostenlosen Account erstellen.
Danach könnt ihr in den Einstellungen einen API Key generieren, den ihr für das folgenden Setup benötigt.

Software installieren

Wir benötigen natürlich einige Softwarepakete. Grundsätzlich, gehe ich davon aus, das ihr UFW bereits installiert habt und entsprechend konfiguriert habt.
Zusätzliche Pakete, die noch benötigt werden:

1
apt install -y screen curl

Ordnerstruktur

Jetzt legen wir den Ordner an, den wir benötigen:

1
mkdir /opt/blacklist

Los geht es

Ok, jetzt fangen wir dann mal wirklich an. Die erste Datei, die wir anlegen heißt blacklist.shund liegt in dem eben von uns erstellten Ordner. Der Inhalt ist klein und fein und sieht so aus:

1
2
3
4
5
6
#!/bin/bash

while read line;
do
ufw insert 1 deny from $line to any;
done < /opt/blacklist/blacklist

Das Script macht nichts anderes, als die Datei /opt/blacklist/blacklist Zeile für Zeile einzulesen und entsprechend an die UFW Firewall zu übergeben und zu blockieren. Richtig, jede Zeile enthält eine potenzielle “böse” IP-Adresse.

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

1
chmod 700 /opt/blacklist/blacklist.sh

Um diese Liste mit den IP-Adressen zu erstellen, benötigen wir noch ein zweites Script, diese legen wir direkt im Verzeichnis /etc/cron.daily/ an. (Achtung, bei schwachen Servern sollte eher in diesem Verzeichnis /etc/cron.weekly/ die Datei angelegt werden). Das Script hat den Namen getBlacklist. Der Inhalt der Datei, sieht wie folgt aus:

1
2
3
4
5
6
7
8
9
10
11
12
#!/bin/bash

#get latest blacklist from abuseIPDB

curl -G https://api.abuseipdb.com/api/v2/blacklist \
-d confidenceMinimum=50 \
-H "Key: EurerAPIKey" \
-H "Accept: text/plain" | sort > /opt/blacklist/blacklist

#block every ip in list

/usr/bin/bash /opt/blacklist/blacklist.sh

Bitte ersetzt EurerAPIKey mit eurem Key, achtet auf das Leerzeichen nach dem Doppelpunkt!

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

1
chmod 755 /etc/cron.daily/getBlacklist

Diese Datei holt die IP-Adressen aus der AbuseIPDB Datenbank und schreibt diese in die blacklist Datei. Danach wird unser erstes Script aufgerufen.
Der Wert confidenceMinimum gibt das folgenden an:

1
Wir empfehlen Ihnen, nach abuseConfidenceScore zu filtern, d.h. nach unserer berechneten Bewertung, wie missbräuchlich die IP ist, basierend auf den Nutzern, die sie gemeldet haben (mehr).

Quelle: AbuseIPDB Dokumentation

Testen

Wichtig: Diese Liste enthält aktuell über 10.000 IP-Adressen

Das Einfügen einer solchen Menge in die Firewall, dauert.
Also werden wir den folgenden Befehl ausführen, nachdem wir screen gestartet haben.

1
2
3
4
screen
# Enter drücken
# dann folgendes ausführen
bash /etc/cron.daily/getBlacklist

Jetzt sollten die IP’s geladen werden und dann alles in die Firewall eingetragen werden.
Mit Strg + a und Strg + d verlasst ihr die aktuelle screen Session.
Um das Ergebnis zu sehen, gebt einfach folgenden Befehl ein:

1
ufw status

Das Bild sollte dann diesem hier sehr ähnlich sein:

In meinem neuen Unternehmen arbeiten wir nur noch mit PostgreSQL Datenbanken. Für ein aktuelles Projekt haben wir jetzt in die Backupstrategie natürlich auch den Dump der jeweiligen Datenbank mit aufgenommen. Im Folgenden will ich kurz erklären, wie es schnell unter Linux mit Cron zu lösen ist.

Dazu legen wir eine Datei an, mit dem Name db_backup.sh.
Diese sollte dann die folgenden Rechte gesetzt bekommen:

1
chmod 700 db_backup.sh

Grund hierfür ist, dass wir in die Datei, das Passwort des jeweiligen DB-Nutzers ablegen müssen.

Als Nächstes kommen wir zum Inhalt:

1
2
3
4
5
6
7
#!/bin/bash

date=$(date +%Y-%m-%d-%H-%M)
export PGPASSWORD=PasswortVomNutzerTest
/usr/bin/pg_dump -C -f /opt/backup/dumps/${date}_postgres_dump.sql --encoding=UTF-8 -U Test

find /opt/backup/dumps -mtime +5 -exec rm {} \;

Okay, gehen wir Zeile für Zeile durch

1
date=$(date +%Y-%m-%d-%H-%M)

Wir legen einen Variabel mit dem Namen date fest, die einen String aus dem aktuellen Datum und Uhrzeit beinhaltet.

1
export PGPASSWORD=PasswortVomNutzerTest

In dieser Zeile legen wir das Passwort vom Nutzer Test fest, was als Umgebungsvariable übergeben wird.
Jetzt kommen wir zum eigentlichen Sicherungsbefehl:

1
/usr/bin/pg_dump -c -C -f  p /opt/backup/dumps/${date}_postgres_dump.sql --encoding=UTF-8 -U Test
  • -c enthält im Dump eine Passage, was beim Importieren die bereits vorhandene DB löscht und alles neu anlegt
  • -C enthält im Dump eine Passage, mit CREATE TABLE Statments
  • -f Speicherort des Dumps (das p bedeutet Plaintext, also SQL)
  • –encoding ist, glaube ich klar :-)
  • -U Angabe des Datenbankbenutzers, hier Test

Und als Letztes ein Befehl der alle Dumps älter als 5 Tage löscht:

1
find /opt/backup/dumps -mtime +5 -exec rm {} \;

Jetzt legen wir noch den jeweiligen Cronjob an und das war’s.

Alle Datenbanken sichern

Um alle Datenbank zu sichern, gibt es den Befehl pg_dumpall:

1
pg_dumpall -U postgres > /opt/backup/all.sql

Hier wird der Benutzer postgres verwendet, was der Default Admin Nutzer ist. Entsprechend sein Passwort muss verwendet werden.

Dokumentation

Weitere Hilfe könnt ihr auch in der Dokumentation finden.

30. Juni 2020

Mozilla hat heute Firefox 78 veröffentlicht. Firefox 78 ist gleichzeitig die neue Basis für Firefox ESR, die Firefox-Version mit Langzeitunterstützung. Während Firefox 78 und Firefox ESR 78 grundsätzlich identisch sind, gibt es doch ein paar wichtige Unterschiede zwischen beiden Versionen. Auch sonst gibt es einiges Wissenswertes für System-Administratoren.

Mozilla hat Firefox 78 und Firefox ESR 78 veröffentlicht. Nutzer von Firefox ESR 68 haben noch acht Wochen Zeit, ehe sie mit Erscheinen von Firefox 80 und Firefox ESR 78.2 am 25. August 2020 automatisch auf Firefox ESR 78 migriert werden. Wie schon Firefox ESR 68 unterscheidet sich auch Firefox ESR 78 in ein paar Aspekten von seinem Mainstream-Pendant.

Download Mozilla Firefox ESR 78

Firefox ESR 78: Kein WebRender

WebRender stammt wie die mit Firefox 57 eingeführte CSS-Engine Stylo ebenfalls aus Mozillas Next-Generation-Engine Servo und ist in der Programmiersprache Rust geschrieben. Es handelt sich bei WebRender um einen Renderer für Webseiten-Inhalte, welcher unter stärkerer Einbeziehung der Grafikkarte als bisher im Grunde wie eine Spiele-Engine arbeitet, aber für das Rendering von Web-Content optimiert ist und dadurch große Performance-Vorteile liefern soll.

Mit Firefox 67 hat es WebRender erstmals in eine finale Version von Firefox geschafft, allerdings erst für einen kleinen Teil der Nutzer. Während Mozilla WebRender weiter verbessert und für immer mehr Nutzer aktiviert, wird WebRender in Firefox ESR 78 für alle Nutzer komplett deaktiviert bleiben.

Firefox ESR 78: System-Zertifikate

Standardmäßig nutzt Firefox seinen eigenen Zertifikatsspeicher und bietet damit eine erhöhte Sicherheit gegenüber anderen Browsern. Im Unternehmensumfeld jedoch ist es häufig gewünscht, dass Zertifikate aus dem Zertifikatsspeicher des Betriebssystems genutzt werden. Darum ist dies in Firefox ESR 78 standardmäßig aktiviert.

Zur Deaktivierung muss der folgende Schalter über about:config auf false geschaltet werden:

security.enterprise_roots.enabled

Firefox ESR 78: Deaktivierte MITM-Erkennung

Nicht nur Schadsoftware, auch sogenannte „Sicherheits“-Software unterbricht verschlüsselte Verbindungen (das heißt Verbindungen über https://) immer wieder, um die Inhalte zu lesen, bevor diese den Browser erreichen, und verkauft dies dann auch noch als Feature. Man spricht dabei von einem sogenannten Man-in-the-Middle („MITM“). Die Folge für Firefox-Nutzer ist aufgrund der häufig mangelhaften Implementierung in einigen Fällen, dass Firefox keine Verbindungen über https:// mehr herstellen kann. Firefox 78 kann Verbindungsprobleme aufgrund von MITM erkennen. Dazu setzt Firefox im Problemfall die Option security.enterprise_roots.enabled auf true und versucht die Verbindung erneut. Funktioniert dies, lässt Firefox die Option auf true, ansonsten wird die Option auf false zurückgesetzt.

Da Firefox ESR 78 den Import von System-Zertifikaten standardmäßig zulässt, ist die MITM-Erkennung in Firefox ESR 78 standardmäßig deaktiviert.

Zur Aktivierung muss der folgende Schalter über about:config auf true geschaltet werden:

security.certerrors.mitm.auto_enable_enterprise_roots

Nur in Firefox ESR 78: Deaktivierbare Signaturpflicht für Add-ons

Zum Schutz seiner Nutzer hat Mozilla eine Signaturpflicht für Add-ons in Firefox eingeführt, welche seit Firefox 43 standardmäßig aktiviert ist. Diese kann nur in Nightly-Builds sowie in der Developer Edition von Firefox deaktiviert werden, nicht in Beta- oder finalen Versionen. Die ESR-Version von Firefox 78 erlaubt auch in der finalen Ausführung die Deaktivierung der Signaturpflicht.

Zur Deaktivierung muss der folgende Schalter über about:config auf false geschaltet werden:

xpinstall.signatures.required

Achtung: Es ist aus Sicherheitsgründen nicht empfohlen, die Signaturpflicht für Erweiterungen zu deaktivieren. Wer seine Erweiterungen ausschließlich über addons.mozilla.org bezieht, findet außerdem in der Regel sowieso ausschließlich signierte Erweiterungen vor.

Nur in Firefox ESR 78: Zusätzliche Enterprise Policy

Seit Firefox 60 liefert Mozilla seine Enterprise Policy Engine aus. Damit ist es für Systemadministratoren möglich, Firefox für die Verteilung im Unternehmen vorzukonfigurieren, wofür bis einschließlich Firefox ESR 52 gerne der sogenannte CCK2 Wizard benutzt worden ist, der allerdings mit Firefox 57 und höher nicht kompatibel ist.

Die SearchEngines-Policy zum Konfigurieren der Suchmaschinen funktioniert ausschließlich in Firefox ESR.

Folgende Unterschiede aus Firefox ESR 68 existieren nicht mehr

Folgende Unterschiede existierten noch zwischen Firefox 68 und Firefox ESR 68, aber nicht mehr zwischen Firefox 78 und Firefox ESR 78:

Service Workers in Firefox ESR verfügbar

Service Workers bezeichnen einen Webstandard, der praktische Anwendungsfälle für moderne Webapplikationen ermöglicht. Firefox unterstützt Service Workers bereits seit Version 44. In Firefox ESR 45, Firefox ESR 52, Firefox ESR 60 und auch noch in Firefox ESR 68 standen Service Workers allerdings nicht zur Verfügung. Mit Firefox ESR 78 sind Service Workers erstmals auch in Firefox ESR verfügbar.

Push-Benachrichtigungen stehen zur Verfügung

Ebenfalls waren Push-Benachrichtigungen bis Firefox ESR 68 noch standardmäßig deaktiviert, da diese Service Workers als technische Voraussetzung haben. Mit der Aktivierung von Service Workers stehen auch Push-Benachrichtigungen ab Firefox ESR 78 zur Verfügung.

Alle Neuerungen zwischen Firefox ESR 68 und Firefox ESR 78

Für einen Überblick über alle wichtigen Neuerungen zwischen Firefox ESR 68 und Firefox ESR 78 empfiehlt sich die Lektüre der Artikel über die Neuerungen der entsprechenden Major-Releases:

Sonstiges Wissenswertes für Unternehmens-Administratoren

Unternehmensrichtlinien und Enterprise Policy Generator

Firefox lässt sich mittels zahlreicher Unternehmensrichtlinien konfigurieren. Dabei gibt es verschiedene Wege: Plattformübergreifend auf Windows, Apple macOS sowie Linux über eine Datei policies.json, via GPO auf Windows oder via .plist-Datei auf Apple macOS.

Die von mir entwickelte Erweiterung Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Die Erweiterung bietet eine einfach verständliche Oberfläche, über welche alle verfügbaren Policies ganz einfach zusammengeklickt werden können, ohne dass Kenntnisse irgendeiner Art notwendig wären – inklusive Möglichkeit, Konfigurationen zu speichern oder für andere Systeme zu exportieren und zu importieren.

Download Enterprise Policy Generator für Firefox

In der aktuellen Version unterstützt der Enterprise Policy Generator noch nicht alle von Firefox 78 unterstützten Unternehmensrichtlinien. Im Juli soll ein großes Update für den Enterprise Policy Generator erscheinen, welches die Unterstützung für zahlreiche neue Unternehmensrichtlinien bringen wird.

MSI-Installer für Windows

Um System-Administratoren im Unternehmen das Anpassen und Verteilen von Firefox einfacher zu machen, bietet Mozilla anpassbare MSI-Installer für Firefox ESR auf Windows 7 und höher an.

MSI-Installer erlauben die Anpassung über eine MST-Datei und können über die auf Windows üblichen Deployment-Tools wie Active Directory oder Microsoft System Center Configuration Manager verteilt werden. Mozilla hat eine Dokumentation zu den MSI-Installern veröffentlicht.

Download MSI-Installer von Firefox ESR 78

pkg-Installer für Apple macOS

Ähnlich zu den MSI-Installern für Windows gibt es pkg-Installer für Apple macOS.

Download pkg-Installer von Firefox ESR 78

Nutzer von Apple macOS 10.9 bis 10.11 werden auf Firefox ESR 78 migriert

Nutzer der Mainstream-Version von Firefox auf Apple macOS 10.9 bis 10.11 werden automatisch auf Firefox ESR 78 migriert und erhalten damit mit Firefox ESR 78 ihr letztes Feature-Update. Nach einem weiteren Jahr Sicherheits-Updates durch Firefox ESR 78 ist für Nutzer von Apple macOS 10.9 bis 10.11 danach Schluss. Bereits Firefox 79 lässt sich auf diesen macOS-Versionen nicht einmal mehr starten.

Veraltete Sicherheits-Protokolle werden nicht länger unterstützt

Unternehmen sollten sicherstellen, dass ihre Seiten üblichen Sicherheits-Standards folgen. Denn mit Firefox 78 unterstützt Firefox nicht länger die veralteten Sicherheitsprotokolle TLS 1.0 sowie 1.1. Das Sicherheitsprotokoll TLS 1.0 ist bereits über 21 Jahre alt. TLS 1.1 bot nur geringfügige Verbesserungen gegenüber TLS 1.0. Aus Sicherheitsgründen ist daher das 2008 finalisierte TLS 1.2 oder noch besser das 2018 finalisierte TLS 1.3 zu nutzen. Ansonsten sieht der Benutzer nur eine Fehlerseite. Außerdem unterstützt Firefox 78 nicht länger die veralteten DHE-Chiffresuiten TLS_DHE_RSA_WITH_AES_128_CBC_SHA sowie TLS_DHE_RSA_WITH_AES_256_CBC_SHA.

Dedizierte Profile pro Installation abschalten

Lesezeichen, Chronik, Erweiterungen, Passwörter, Einstellungen – diese und noch weitere Dinge werden in einem sogenannten Profil gespeichert. Verschiedene Firefox-Installationen nutzen bisher standardmäßig immer das gleiche Profil.

Seit Firefox 67 nutzt der Mozilla-Browser dedizierte Profile pro Installation. Das heißt, dass wenn ein Nutzer mehrere Firefox-Installation hat, jede dieser Installationen ein eigenes Profil verwendet und damit standardmäßig nicht länger in allen Installationen automatisch die gleichen Lesezeichen, die gleiche Chronik etc. zur Verfügung stehen.

Gerade im Unternehmensumfeld kann dies unerwartet sein. Über eine Umgebungsvariable mit beliebigem Wert kann dieses Feature abgeschaltet werden:

MOZ_LEGACY_PROFILES

Wie Umgebungsvariablen angelegt werden, ist der Dokumentation des jeweiligen Betriebssystems zu entnehmen.

Downgrade-Schutz abschalten

Ein anderes Feature seit Firefox 67 ist ein Downgrade-Schutz. Firefox verhindert, dass der Browser mit einem Profil gestartet wird, welches bereits mit einer neueren Firefox-Version genutzt worden ist. Auch dieses Feature kann über eine Umgebungsvariable mit beliebigem Wert abgeschaltet werden:

MOZ_ALLOW_DOWNGRADE

Alternativ dazu kann Firefox mit dem folgenden Kommandozeilen-Argument gestartet werden:

--allow-downgrade

Dokumentation für System-Administratoren

Hier gibt es spezielle Hilfe-Seiten für die Administration von Firefox im Unternehmen.

Der Beitrag Alles Wissenswerte zu Firefox ESR 78 inklusive Unterschiede zu Firefox 78 erschien zuerst auf soeren-hentzschel.at.

29. Juni 2020

Mit Hubs hat Mozilla vor zwei Jahren eine soziale Plattform für Virtuelle Realität gestartet. Die Hubs Cloud ermöglicht es nun, eigene Instanzen der Hubs-Plattform zu betreiben.

Vor zwei Jahren hat Mozilla Hubs gestartet, eine soziale Platttform für Virtuelle Realität (VR). Das Besondere an Hubs: es spielt sich komplett im Web ab – keine geschlossene Plattform, keine Installation einer Anwendung, keine Abhängigkeit von einem bestimmten Gerät. Einfach eine URL teilen und miteinander treffen. Hubs funktioniert in jedem Browser, am Smartphone und natürlich auch mit der VR-Brille.

Mit der Hubs Cloud hat Mozilla ein Angebot gestartet, welches es ermöglicht, seine eigene Hubs-Instanz zu betreiben. Dabei gibt es mit der Hubs Cloud Personal und der Hubs Cloud Enterprise zwei Optionen, welche funktional identisch sind, sich aber in der Skalierbarkeit und im Preis voneinander unterscheiden. Derzeit wird die Hubs Cloud sowohl über Amazon AWS als auch über Digital Ocean angeboten. Weitere Anbieter können in der Zukunft folgen.

Administratoren können in der Hubs Cloud ihre eigenen Räume und Avatare konfigurieren und natürlich auch das Branding an das Unternehmen anpassen. Dazu gibt es eine eigene Administration mit vielen Optionen.

Hubs Cloud

Hubs Cloud

Der Beitrag Hubs Cloud: Eigene Instanz von Mozillas Hubs-Plattform betreiben erschien zuerst auf soeren-hentzschel.at.

Nun also auch Mozilla und Google: nachdem Apple bereits vor einiger Zeit vorangegangen ist, die Gültigkeitsdauer der HTTPS-Zertifikate zu begrenzen, ziehen jetzt Mozilla und Google nach. Diese generelle Diskussion ist schon seit einiger Zeit auf Thema im CA Browser Forum, dort stieß es bis zuletzt noch auf Widerstand seitens der CAs.

Konkret ist die Änderung: ab 01.09.2020 werden Zertifikate abgelehnt, deren Gültigkeitsdauer 398 Tage überschreitet. Bei Chromium ist die bisherige maximale Gültigkeitsdauer 825 Tage (ab 2018-03-01).

Als Argument für diese Verschärfung wird das als kaputte bezeichnete Widerrufsverfahren, implementiert durch CRLs und OCSP, aufgeführt.

Meinung

Während vor 10 Jahren Google gerade auf Default-HTTPS umstellte und die Wikpedia noch lediglich über https://secure.wikimedia.org/wikipedia/de/ HTTPS-Verschlüsselung bereitstellte, sieht das heute mittlerweile fundamental anders aus.

Mit Let's Encrypt ist auch das Kostenargument widerlegt worden, sodass es TLS-Zertifikate für die HTTPS-Verbindungen mittlerweile selbst als Beigabe bei Hostern oder CDNs gibt. Bereits bei Let's Encrypt war ich allerdings verwundert, warum die Zertifikate nur 90 Tage laufen. Automatisierung, so hieß es, löst das Problem.

Hieraus lässt sich der Trend erkennen, dass Zertifikate von Goldstaub, der teuer und aufwändig gekauft werden musste, zu Allerweltsgut werden. Und zwar durch kürzere Laufzeiten und die Reduktion auf das Wesentliche: eine Transportverschlüsselung zu einem Server mit einem DNS-Namen. Vielleicht werden wir irgendwann die Laufzeit von 1 Tag haben, so wie mir das bereits beim elektronischen Personalauweis bei den Berechtigungszertifikaten über den Weg gelaufen ist. (aber dort ist die Zielsetzung sicherlich auch anders, zudem weiß ich nicht, wie da der aktuelle Stand ist)

Schnell wechselnde Zertifikate sind nicht nur ein administrativer Aufwand (der sicherlich bei Automatisierung nur einmalig ist), sondern verbauen den Weg fürs praktikable Fingerprinting („hier der Fingerprint von meinem Cert, wenn der nicht mehr stimmt, dann stimmt vielleicht was nicht... ruf mich dann mal an“). Aber das wurde ja in der Implementierung durch Key Pinning mit HPKP schon länger abgekündigt. Von Extended Validation-Certs (bringen die noch optisch was?) ganz zu schweigen. Glückt einem Angreifer also ein DNS Spoofing-Angriff, so hat dieser leichteres Spiel, da die trivialen Warnmöglichkeiten wie das angesprochene Key Pinning nicht mehr Standard sind und Sperrlisten von den Browserherstellern gar nicht mehr als Weg betrachtet werden.

Es geht also zukünftig weniger um die Vorstellung eines Schutzes einer Verbindung zu einem Server mit einem DNS-Domainnamen einer Person/Organisation XYZ, sondern lediglich um das Wesentliche eines DV-Zertifikats: den Schutz einer Verbindung zu einem Server mit einem DNS-Domainnamen.

Aber ich drifte wohl zu sehr in die Intranet-Welt ab. Die soll das eh nicht so betreffen, da laut Apple eigens hinzugefügte CAs nicht von den neuen Regeln erfasst sein sollen. In Chrome ist das scheinbar ebenfalls so, jedenfalls, wenn dieses is_issued_by_known_root sich auf Public CAs bezieht (konnte das bisher auf die Schnelle nicht genau nachvollziehen, wurde aber in Kommentaren so angedeutet).

Ich kann beide Seiten verstehen. Bleibt die Frage, ob maximale Anforderungen auch die maximale Sicherheit mit sich bringt.

Weitere Quellen

In der Einführung in Red Hat Insights habe ich kurz umrissen, worum es sich bei dieser SaaS-Anwendung handelt und wie man RHEL-Systeme einrichtet, um den Dienst nutzen zu können. Dieser Artikel widmet sich dem Menüpunkt „Advisor“ im Insights-Dashboard.

Das Insights-Dashboard ist erreichbar unter der URL: https://cloud.redhat.com/insights/dashboard

shows-rh-insights-dashboard
Bild 1: Übersicht im Insights Dashboard

Das Dashboard gibt einen Überblick darüber, wie viele Systeme aktuell in Insights eingebunden sind, ob es Probleme mit bekannten Systemen gibt, den Patch-Status, Schwachstellen, Compliance-Status, durchgeführte Remediations und Advisor recommendations. Letztere sind Gegenstand dieses Artikels und werden im Folgenden einer genauen Betrachtung unterzogen.

Advisor recommendations bedeutet auf Deutsch soviel wie „Empfehlungen eines Ratgebers“. Der Ratgeber (Advisor) ist in diesem Fall die Firma Red Hat, welche mit Machine Learning Algorithmen, ihrer Erfahrung und dem aus Kunden-Support-Fällen gesammelten Wissen, Ratschläge zur Systemkonfiguration und Hinweise auf Konfigurationsfehler unterbreitet.

Das Dashboard in Bild 1 zeigt, dass Insights für die 13 verbundenen Systeme insgesamt 5 Empfehlungen bereithält, mit denen die Systemkonfiguration verbessert werden kann.

Über das Menü am linken Rand oder den Link im Feld der Advisor recommendations gelangt man auf die Unterseite des Ratgebers, welcher die Empfehlungen in einer Übersicht mit Bewertung darstellt (siehe Bild 2).

Show Advisor recommendations view
Bild 2: Übersicht der Advisor Recommendations

Die tabellarische Übersicht in Bild 2 zeigt die Empfehlungen mit einer kurzen Beschreibung, seit wann diese Empfehlung im Insights existiert, eine Risikobewertung, wie viele Systeme davon betroffen sind und ob ein Ansible-Playbook existiert, mit dem das beschriebene Problem in der eigenen Infrastruktur behoben werden kann.

Auf die einzelnen Funktionen der Seite aus Bild 2 werde ich im Folgenden näher eingehen, während ich eine Bewertung der angezeigten Empfehlungen vornehme.

Als erstes sticht mir der zweite Punkt ins Auge. Mit einem Klick auf den Pfeil vor der Beschreibung werden weitere Details eingeblendet (siehe Bild 3). Hier erfährt man, dass es vermutlich kein Problem darstellt, wenn man zum jetzigen Zeitpunkt kein In-Place-Upgrade auf RHEL 8 durchführt und dass ein Upgrade vermutlich ein Wartungsfenster mit Downtime benötigt. Weitere Informationen bietet der verlinkte Knowledge-Base-Artikel.

Zeigt wie ein Eintrag deaktiviert werden kann
Bild 3: Detailansicht eines Eintrags und Funktion zum Deaktivieren dieser Empfehlung

Ich persönlich bewerte die in Bild 3 ausgewählte Empfehlung als unnütz. RHEL 7 ist immer noch ein Release unter Wartung, welches Sicherheits-Aktualisierungen erhält. Dass RHEL 8 inzwischen in Version 8.2 erschienen ist und mit neuen Funktionen und Verbesserungen aufwartet, ist bekannt, aber kein Grund für übereilte Upgrades. Darüber hinaus führen wir im BITS in der Regel keine In-Place-Upgrades durch. Stattdessen installieren wir eine neue virtuelle Maschine (VM), migrieren Daten und Dienste und schalten anschließend den alten Host ab.

Zum Glück muss man sich von unbedeutenden Meldungen nicht ewig nerven lassen. Wie in Bild 3 zu sehen, bietet Insights die Möglichkeit, Meldungen einfach zu deaktivieren. Sehr schön empfinde ich dabei, dass man einen Grund angeben kann (siehe Bild 4). So wird man auch nach Wochen oder gar Monaten daran erinnert, warum man einen Eintrag deaktiviert hat.

Shows justification note dialog
Bild 4: Insights bietet die Möglichkeit einen Grund für die Deaktivierung einer Empfehlung anzugeben

Anschließend wird der Eintrag in der Übersicht nicht mehr angezeigt (vgl. Bild 5).

Show only enabled recommendations
Bild 5: Mit dem automatisch aktivierten Filter werden nur noch aktive Einträge angezeigt. Deaktivierte Elemente werden ausgeblendet.

Nach dem Deaktivieren eines Eintrags kam mir sofort die Frage in den Sinn, wo ich diese denn wohl wiederfinden kann. Dies ist über die Filtereinstellungen im oberen Bereich der Seite möglich (siehe Bild 6).

Show disabled recommendations
Bild 6: Anzeige der deaktivierten Elemente

An dieser Stelle möchte ich erwähnen, dass das Insights-Team die entsprechende Empfehlung nach meiner Rückmeldung komplett aus Insights entfernt hat. Schön, dass man als Kunde hier Gehör findet.

Bewertung der weiteren Empfehlungen

Es bleiben noch vier weitere Empfehlungen, die ich im Folgenden für meine konkrete Umgebung bewerten will. Alle vier haben gemein, dass ich vermutlich nie bewusst nach diesen Konfigurationseinstellungen gesucht hätte. Und zumindest zwei sind dabei, bei denen ein genauerer Blick lohnt. Und mit diesen fange ich an.

OS boot failure occurs due to uncertain disk discovery order when /dev/sdN format device names are used in /etc/fstab

Hier wird auf eine Konfiguration hingewiesen, die im ungünstigsten Fall den Bootvorgang eines Hosts verhindert. Eine Einstufung als „Important“ ist daher nachvollziehbar. Lässt ein System, das nicht startet, doch regelmäßig den Puls und Adrenalinspiegel eines Sysadmin steigen.

Um mir das (mögliche) Problem näher erläutern zu lassen, rufe ich aus der Detailansicht den dort verlinkten Knowledge-Base-Artikel auf. Dabei fällt mir auf, dass, obwohl ich ausschließlich RHEL 7 Systeme verwende, auf einen Artikel verlinkt wird, der nur für RHEL 6 gilt. Immerhin findet sich in diesem eine Referenz zum entsprechenden Artikel für RHEL 7. Hier hätte man gleich passend verlinken können.

Wie ist dieser Eintrag nun für uns zu bewerten?

Die beiden betroffenen Systeme sind schon einige Zeit in Betrieb und haben bereits mehrere Neustarts ohne Probleme überstanden. Das potenzielle Problem scheint sich zumindest in unserer Umgebung nicht negativ auszuwirken.

Insights bietet für diesen Fall die Erstellung eines Ansible-Remediation-Playbooks an, mit welchem das Konfigurationsproblem behoben werden kann. Da ich in diesem Fall nicht der System-Betreiber für die beiden aufgeführten Systeme bin, kann ich dies jedoch nicht ohne Rücksprache mit dem entsprechenden Kollegen zur Ausführung bringen.

Ich habe den entsprechenden System-Betreiber über dieses Ereignis benachrichtigt, ihm die mögliche Lösung weitergeleitet und ihm die Entscheidung überlassen, wie er weiter damit verfahren möchte. Dieser hat sich für den Hinweis bedankt und das Problem sofort behoben.

In einem späteren Artikel werde ich mich noch damit beschäftigen, wie ich Kollegen Zugriff auf das Insights-Dashboard gewähren kann, so dass diese ihre Systeme darin selbst verwalten und untersuchen können.

Traffic occurs or services are allowed unexpectedly when firewall zone drifting is enabled

Dies ist aus meiner Sicht wirklich ein interessanter Fund. Denn er weist darauf hin, dass womöglich Kommunikation durch die lokale Host-Firewall erlaubt wird, obwohl dies nicht beabsichtigt ist (vgl. Bild 7).

Show further details of a recommendation
Bild 7: Recommendations lassen sich über den Pfeil am Anfang einer Zeile aufklappen, um weitere Informationen zu sehen.

Auch hier liefert der verlinkte Knowledge-Base-Artikel ausführliche Informationen.

Ich werde diesen Punkt auf jeden Fall mit dem betroffenen Kollegen thematisieren. Ich denke, dass hier ein kleiner Wissenstransfer angebracht ist, da nach meiner Einschätzung auch weitere Kollegen sich des konkreten Verhaltens nicht bewusst sind. Von daher bewerte ich diesen Ratschlag als gut und sinnvoll.

Ein Punkt übrigens, der mir am Insights-Dashboard allgemein gut gefällt, ist, dass ich jederzeit anzeigen lassen kann, wie viele Systeme betroffen sind und noch wichtiger, welche dies sind (siehe Bild 8).

Show affected systems
Bild 8: Ansicht der betroffenen Systeme

Decreased security: httpd serving unencrypted (HTTP) traffic

Dies ist eine Meldung mit niedriger Risiko-Einstufung und so werden wir sie auch behandeln. Bei den betroffenen Systemen handelt es sich um Test-Systeme. Der System-Betreiber hat hier bewusst auf die Implementierung von TLS/SSL verzichtet.

Decreased security: Yum GPG verification disabled (third-party repos)

Dieser Punkt stellt sich wider Erwarten als interessant heraus. Wir betreiben eigene Repositories, welche nur innerhalb unserer Einrichtung verwendet werden. Um den Aufwand zu minimieren, verzichten wir bei diesen auf die Signierung der Pakete.

Überraschend ist jedoch der Umstand, dass bei einigen Hosts auch die GPG-Signatur-Überprüfung für ein gespiegeltes RHEL-Repo deaktiviert ist. Um dies herauszufinden, muss man sich nicht erst zu einem betroffenen System verbinden und dies untersuchen. Es genügt ein Klick auf den Hostnamen in der Liste der betroffenen Systeme (vgl. Bild 8), um zu einer Ansicht zu gelangen, die neben einer ausführlichen Beschreibung auch einen Lösungsweg anbietet.

Insights bietet nicht nur Unterstützung dabei herauszufinden, was falsch ist, sondern auch wie man das Problem abstellt. Ich werde im Laufe des Tests fortlaufend überprüfen, wie häufig Insights hier mit sinnvollen Lösungen aufwarten kann.

Slow system boot when storage devices do not support WRITE SAME command

Neu hinzugekommen und daher in obigen Bildern noch nicht enthalten ist dieser Hinweis auf ein Problem, welches die Leistung des Systems beim Bootvorgang reduzieren kann.

Insights hat diesen Incident erkannt, nachdem das betroffene System neugestartet wurde, der insights-client erneut gelaufen ist und Insights eine entsprechende Meldung in /var/log/messages gefunden hat.

Das Problem selbst ist uns seit langem bekannt. Es fällt allerdings in die Kategorie: „Gucken wir uns an, wenn wir mal Zeit haben.“ Also vermutlich nie. Zum Glück booten unsere VMs innerhalb weniger Sekunden und es wird hier kein Problem wahrgenommen.

Zwischenfazit

Ich stehe noch am Anfang unseres Tests. Die bisherigen Erkenntnisse lassen daher noch keine abschließende Bewertung zu, ob ein dauerhafter und ausgedehnter Einsatz von Insights gerechtfertigt ist.

Als erster Eindruck bleibt eine benutzerfreundliche Oberfläche, welche eine intuitive Bedienung gestattet. Der Advisor enthält bis jetzt neben einigen belanglosen Empfehlungen auch interessante Hinweise.

28. Juni 2020

Da ich in letzter Zeit durch eine Kombination aus fehlenden Treibern für irgendwelche Updates 4x meinen Rechner neu installieren musste, habe ich mich mal nach einem System Snapshot Tool umgesehen. Also ein Programm, mit dem ich den aktuellen Status meines Systems festhalten kann und bei einem fehlerhaften Update einfach alles wieder “zurück rollen” kann.

 

Ich bin dabei auf das Programm Timeshift gestossen https://github.com/teejee2008/timeshift . Das macht exakt genau das. Es erstellt eine exakte Kopie des aktuellen Systems als Snapshot. Dabei werden aber KEINE Benutzerdaten gesichert! Also alle Verzeichnisse unter /home/ oder /root werden NICHT gesichert. Das will ich auch nicht, denn ein Backup dieser Daten mache ich sowieso schon mit rsync auf eine externe Platte.

 

Wichtig und daher nochmal: Timeshift ist nicht dazu gedacht deine Benutzerdaten, Dokumente, Bilder usw zu sichern. Timeshift erstellt quasi sowas wie einen Wiederherstellungspunkt, falls man ein Systemupdate gemacht, oder aus Versehen Blödsinn mit dem System angestellt hat und irgendwas schief gegangen ist. So kann man ganz einfach einen vorherigen lauffähigen Stand des Systems wieder herstellen.

 

Bei meinem aktuellen Kubuntu 20.04 System mit weiteren installierten Programmen rund um Audio-, Video- und Bildbearbeitung sind das ungefähr 7GB, die auf der Festplatte Platz finden müssen. Bei jedem weiteren Snapshot werden aber nicht wieder 7GB verbraucht, so dass man bei 2 Snapshots 14GB Speicherplatz verbraten hätte. Timeshift macht das inkrementell. Das heisst, dass nur veränderte Dateien neu gespeichert werden. Dateien, die gleich geblieben sind, werden einfach nur mit Links referenziert. Die Snapshots speichert timeshift im Verzeichnis /timeshift/

 

Installation

Installiert wird Timeshift unter Kubuntu 20.04 mit dem einfachen “Dreisatz” in der Konsole

  1. sudo add-apt-repository -y ppa:teejee2008/timeshift
  2. sudo apt-get update
  3. sudo apt-get install timeshift

 

Snapshot erstellen

Danach kann man dann das Programm Timeshift im Startmenü aufrufen (oder auch in der Kommandozeile, falls man das Programm auf einem Server benutzt).

  1. Zuerst muss man das Passwort eingeben, da das Programm mit root Rechten arbeiten muss
  2. Dann wird man gefragt, ob man rsync oder BTRFS benutzen möchte. Rsync ist standardmäßig ausgewählt und solange ihr nicht wisst, ob ihr ein BTRFS Filesystem habt, benutzt bitte rsync !
  3. Schliesslich wird einem angeboten, dass automatisch und regelmäßig ein Snapshot erstellt wird. Das habe ich deaktiviert, da ich ein Snapshot jeweils selbst erstellen möchte z.B. wenn ich ein Systemupdate machen möchte, oder neue Treiber einspielen will.

 

Snapshot wieder herstellen
Damit man wieder auf einen alten Snapshot Stand zurück kommt, muss man einfach Timeshift erneut aufrufen und auf den entsprechenden Eintrag klicken und “Wiederherstellen” klicken. Dann wird verglichen, die Änderungen werden angezeigt, man bestätigt die Wiederherstellung und schliesslich wird der Rechner neu gestartet, womit man auf dem Stand des Snapshots landet.

 

Timeshift ohne grafische Oberfläche
Hat man aber keine grafische Oberfläche mehr, so muss man sich der Kommandozeile bedienen.

  1. Ein Snapshot erstellt man mit : sudo timeshift --create --comments "Mein Snapshot"
  2. Die Snapshots kann man sich anzeigen lassen mit sudo timeshift --list
  3. Ein Snapshot wird wieder hergestellt mit : sudo timeshift --restore --snapshot '2020-06-28_19-02-58'
  4. Eine Hilfe bekommt man angezeigt, wenn man einfach nur sudo timeshift eingibt.

 

Sempervideo hat dazu ein nettes Tutorial mit der grafischen Oberfläche von Timeshift erstellt https://youtu.be/c403EsC7g1k

 

 

27. Juni 2020

Wenn man per sudo apt youtube-dl das Programm installiert bekommt man bei einem Aufruf von youtube-dl eine Fehlermeldung, als wäre python nicht installiert. Es fehlt aber lediglich das Alias /bin/python . Das kann man ganz einfach korrigieren, indem man den folgenden Befehl eingibt:

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1000

Man sollte man noch das Programm curl mit sudo apt install curl installieren, da youtube-dl curl bei manchen Operationen benutzt.

 

 

26. Juni 2020

acme.sh - Let's Encrypt-Client mit Hetzner-DNS-API nutzen

Ein kleiner Quick-Tipp. Schon seit einiger Zeit bin ich von certbot auf den alternativen Let's Encrypt-Client acme.sh gewechselt. Der Vorteil für mich ist, dass dieser anders als Certbot nicht unzählige Abhängigkeiten von Python benötigt.

Im April hatte Hetzner eine neue DNS-Console veröffentlicht. Nach einem doch eher holprigen Start läuft diese für mich mittlerweile sehr rund.
Seit nun wenigen Wochen wird nun auch die neue Hetzner-DNS-Api von acm.esh unterstützt, was unter anderen auch Wildcard-Zertifikate von Let's Encrypt ermöglicht.
Einzige Bedingung ist, dass die DNS-Zone der Domain in der neuen DNS-Console von Hetzner liegen muss.
Alles was man dann tun muss ist im API Management einen neuen Key zu generieren. Auf der Konsole sind dann folgende Befehle notwendig:

export HETZNER_Token="DeinToken"
acme.sh --issue --dns dns_hetzner -d timscha.io -d '*.timscha.io'

Und schon hat man, wenn alles geklappt hat ein kostenloses Wildcard-Zertifikat für seine Domain.
Das Token wird anschließend in die account.conf im Home-Verzeichnis von acme.sh gespeichert, somit spart man sich das erneute setzen der Variable.