Keine mehr, weil micht mehr gefragt. Zu Zeiten als IT-Skill noch gefragt war, [...]
Gerade professionelle Admin-Skills im Unix-Umfeld sind aktuell wahnsinnig gefragt. Alle mir bekannten (Nicht-Windows-)Admins können sich vor Anfragen und Abwerbeversuchen kaum retten.
Vermutung: keine, weil die alle auf Windows basieren?
Ein Gegenbespiel ("We are aware of targeted attacks in the wild abusing this flaw."):
https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/#CVE-2019-17026
Der aktiv ausgenutzte Bug erlaubt die Ausführung beliebigen JavaScript-Codes und ist - dank JavaScript - unabhängig vom darunterliegenden Betriebssystem.
Was soll denn "nur" alle drei Monate heißen?
Viele vernetzte Systeme können beim besten Willen keine drei Monate mit der Installation von Security-Fixes warten. Bis dahin wird schon längst auf breiter Front probiert, die Sicherheitslücken auszunutzen.
Und da ersteres m.E. die Grundrechte verletzt, werden Apfelkisten grundsätzlich nicht gepatcht.
Sollte die Konsequenz nicht heißen, grundsätzlich keine "Apfelkisten" zu verwenden?
Heute dagegen heißt es, dass man eine Datenbank gar nicht direkt ins Backup sichern darf, weil die Leute üblicherweise zu blöd sind um das richtig zu machen.
Quelle?
Du solltest die laufende Datenbank natürlich mit den Datenbank-eigenen Bordmitteln sichern (
mysqldump,
pg_dump etc.). Alles andere (inklusive ZFS-Snapshots) produziert inkonsistente Backups. Damit können die meisten Datenbanken dank
WAL und andere Mechanismen umgehen, ist aber trotzdem grob fährlässig.
Genau: der DAU als Standard.
Nachdem IT-ler in der Gesamtbevölkerung nur einen kleinen Anteil ausmachen, ist im Bereich Browser der DAU tatsächlich der Standard.
Um bei Autovergleichen zu bleiben: wer hier im Forum ist beim Auto kein DAU und könnte ad hoc eine Zylinderkopfdichtung tauschen?
Dann verfügst Du über Informationen welche in diesem Fall sehr hilfreich sein können. Ist es dir möglich, diese uns zur Verfügung zu stellen, damit wir, aus hoffentlich seriöser Quelle, erfahren können, wie hoch der Umfang an Schaden ist, welcher durch zwei Jahre alte ungepatchte FeuerFüchse ist?
Ich wüsste nicht, dass eine solche Datenbasis überhaupt existiert (vielleicht noch beim Google-Chrome-Team).
Worauf ich hinaus will: mit einem nicht aktuellen Browser bist du auf jeden Fall verwundbar und hast eine realistische Chance, Opfer zu werden.
Du bezichstigst den Endanwender ein wesentlicher Teil des Problems zu sein.
Meine Aussage ist genau umgekehrt: ich will, dass der Endanwender null IT-Kenntnisse haben muss und trotzdem eine sichere und benutzbare Umgebung vorfindet.
Kurze Zwischenfrage: Da diese Systeme in der Regel aktuell sind, sollten diese nach deiner Argumentation nicht zu den Problemfällen zählen, oder sehe ich das falsch?
Mit einem alten Browser unter FreeBSD wirst du leichter Opfer einer Sicherheitslücke als mit einem aktuellen Edge unter einem aktuellen Windows.
Es gibt halt auf dem Desktop für jeden FreeBSD-User zehntausende Windows-User, weswegen BSD auch keine mediale Aufmerksamkeit bekommt. Viele BSD-Nutzer wägen sich deswegen in trügerischer Sicherheit.
Sag mir jetzt bitte nicht, dass Du bei Produktiv-Systemen die automatischen Updates aktivierst? Moment, doch, das tust Du!
Meine üblichen Betriebssystem-Updates in Produktion laufen folgendermaßen:
- CI-Server erkennt eine neue OS-Version
- Neues Base-Image wird gebaut, konfiguriert und in der Testumgebung ausgespielt
- Automatische Tests laufen gegen die Testumgebung
- Neues Image wird via Rolling Update in Produktion ausgespielt und via Monitoring automatisiert beobachtet
Gib es irgendwo oben in der Liste ein Problem oder zeigt das neue Image in der Produktion eine erhöhte Fehlerrate, wird das Deployment automatisch rückabgewickelt und ein Admin benachrichtigt, der es sich anschaut.
Ich wüsste nicht, wo ich hier ich durch einen manuellen Schritt das System verbessern könnte. Oder siehst du einen?
Du gehst also davon aus, dass der Distributor deinen Job macht?
Ich gehe grundsätzlich davon aus, dass Menschen Fehler machen und irgendwas schiefgeht. Deswegen habe ich bei meinen Kunden alles soweit automatisiert, dass der Gutfall keinen Aufwand und der Schlechtfall keine Produktionsprobleme verursacht.
Der Endanwender ist überhaupt nicht mehr in der Lage einen modernen Browser zu administrieren.
Auf den gängigen Plattformen sollte der 08/15-Anwender auch nichts administrieren müssen. Soweit ich weiß, sind Chrome, Edge und Firefox auch ohne administrative Eingriffe für Endanwender nutzbar.
Auf die Frage: "Warum kann man denn so was dort einstellen?", darauf hätte ich keine plausible Antwort. Aber vielleicht kann mir Azazyel ja eine liefern?
Die von mir gepriesenen
reasonable defaults im Browser sollten für den 08/15-Anwendungsfall genügen.
Für alle anderen Anwendungsfälle (z.B. im Unternehmenseinsatz) muss man ja trotzdem die Möglichkeit haben, an der Konfiguration zu drehen, falls die Voreinstellungen für den eigenen Anwendungsfall nicht passen.
Da war mit Sicherheit kein veralteter Browser das Problem.
Der Einsatz eines veralteten Browsers schafft ein
zusätzliches Problem und Einfallstor, zusätzlich zu den ganzen anderen Problemen die wir so haben.
Das Patches/Updates überhaupt notwendig sind ist kein Qualitätsmerkmal, sondern ein Mangel.
Stand heute ist es uns nicht möglich, fehlerfreie Software jenseits von
Hello World zu schreiben. In Anbetracht der mangelnden Praxistauglichkeit der formalen Verifikation wird das auch noch lange so bleiben.
Patches/Updates heißt sind ja deswegen positiv besetzt, weil sich zumindest jemand um die Behebung der unvermeidbaren Fehler kümmert.
Genau eine solche Einstellung ist vermutlich auch der Grund für etliche Sicherheitslücken. Kost ja nix, also können wir mit Speicher rumaasen. Und wenn der Arbeitsspeicher nicht reicht, dann stecken wir halt noch mal 16 GB hinterher -- kost ja nix mehr.
Gerade RAM-intensive Programmiersprachen wie Python oder Java verhindern viele mögliche Sicherheitslücken wie Buffer Overflows, die das RAM-schonende C plagen.
Mich selber ärgert es, dass mit dem Finger auf User gezeigt wird (Das Böööööööööse!) weil diese auf einem nicht mehr supporteten BS einen aktuellen FireFox installieren möchten.
Sollen wir die User anlügen und sagen, die Kombination aus aktuellem Firefox und altem MacOS kann er bedenkenlos einsetzen?
Damit ist doch auch niemandem geholfen.