Antary Blog

Die Zukunft von DNS? DNS over TLS (DoT) und DNS over HTTPS (DoH)

Das mittlerweile über 30 Jahre alte Domain Name System (DNS) ist nach wie vor einer der wichtigsten Dienste in vielen IP-basierten Netzwerken. Die Hauptaufgabe von DNS ist die Namensauflösung, d.h. die Umsetzung von Domainnamen in IP-Adressen. Große Probleme bei DNS sind die fehlende Sicherheit und Privatsphäre. Die DNS-Kommunikation findet über UDP-Port 53 im Klartext statt und kann daher quasi von jedem mitgelesen und manipuliert werden. Die Missbrauchsmöglichkeiten von DNS sind erschreckend einfach umzusetzen, was viele Fälle in der Vergangenheit zeigen. Darüber hinaus können Nachrichtendienste, Provider und Betreiber von DNS-Servern die DNS-Kommunikation mitlesen und wissen, wer wann welche Internetadressen bzw. -dienste aufgerufen hat. Damit lassen sich Nutzerprofile erstellen und eine großflächige Überwachung realisieren. Einige Anbieter von DNS-Servern nutzen die Daten unter anderem auch für Werbezwecke.

Spätestens jetzt sollte jedem klar sein, dass die ursprüngliche Implementierung von DNS deutliche Nachbesserungen in den Bereichen Privatsphäre, Datenschutz und Sicherheit benötigt.

DNSSEC

Diese Probleme wurden schon früher erkannt. Einige wollte man bereits im Jahr 1999 mittels DNSSEC (Domain Name System Security Extensions) angehen. Die erste Implementierung (RFC 2535) erwies sich jedoch als nicht praxistauglich, weshalb 2005 eine Neufassung von DNSSEC veröffentlicht wurde (RFC 4033). Damit wird DNS um Sicherheitsmechanismen zur Gewährleistung der Authentizität und Integrität der Daten erweitert. Konkret bedeutet dies, dass Zonen signiert werden und DNSSEC-Nutzer somit die Echtheit einer DNS-Anfrage verifizieren können. Wenn die Signatur ungültig ist, werden die Daten verworfen. Auf den Root-Nameservern wurde DNSSEC im Mai 2010 eingeführt.

Allerdings hat sich DNSSEC immer noch nicht flächendeckend durchgesetzt. Die Hauptgründe liegen an der als kompliziert geltenden Umsetzung (ein Relikt aus den Anfangszeiten) und daran, dass nicht alle Probleme von DNS gelöst werden. Beispielsweise werden nach wie vor alle Daten unverschlüsselt übertragen und können mitgelesen und archiviert werden. Des Weiteren werden die Manipulationsmöglichkeiten nicht vollständig unterbunden und einige Provider unterstützen noch immer kein DNSSEC auf ihren DNS-Resolvern. Bei Interesse kann diese Information auf https://internet.nl über den Punkt “Test your connection” geprüft werden. Unabhängig davon bleibt die “letzte Meile” dennoch in fast allen Fällen ungesichert. Ein Großteil der Heimrouter und so gut wie alle Betriebssysteme und Browser unterstützen kein DNSSEC. Damit kann der User nach wie vor nicht darauf vertrauen, dass die DNS-Antworten korrekt sind.

Bei DNSSEC sind die Daten zumindest digital signiert. Die Übertragung erfolgt jedoch im Klartext. Zwischen User und Provider-DNS-Server sind die Daten fast immer komplett ungesichert.

Daraufhin wurden in den letzten Jahren mehrere Protokolle mit dem Ziel entwickelt, die fehlende Privatsphäre und den nicht vorhandenen Datenschutz nachzurüsten. Dies geschieht mittels Verschlüsselung. Mittlerweile haben sich zwei Favoriten durchgesetzt: DNS-Anfragen werden entweder mit TLS verschlüsselt (DNS over TLS (DoT) ) oder in HTTPS verpackt (DNS over HTTPS (DoH)). Anderen Alternativen wie DNSCurve oder DNSCrypt sind faktisch tot.

DNS over TLS (DoT)

Das Prinzip von DoT (RFC 7858 und RFC 8310) ist simpel. Die DNS-Informationen werden über eine TCP-Verbindung mit dem Resolver ausgetauscht, die via Transport Layer Security (TLS) authentifiziert und verschlüsselt ist. Damit können Nutzer die gewünschten Daten vom Nameserver beziehen, ohne dass Dritte mitlesen können. Eine Validierung der DNS-Daten erfolgt nicht durch DoT, deshalb sollte DoT immer in Kombination mit DNSSEC verwendet werden.

Schauen wir uns DNS over TLS genauer an. Die Kommunikation läuft über den TCP-Port 853. Sollte dies nicht funktionieren, ist in der Regel das “normale” DNS via UDP-Port 53 als Fallback aktiv. Dies ist aber von den Sicherheitseinstellungen des Systems abhängig. In der Praxis dürfte dies vor allem in Unternehmen und öffentlichen WLAN-Hotspots problematisch sein, da der relativ unbekannte TCP-Port 853 hier vermutlich blockiert wird. Mit dem Zurückfallen auf UDP-Port 53 ist DoT nutzlos, ohne Fallback funktioniert die Namensauflösung auf dem Client nicht mehr. Ein weiteres Problem ist der relativ große Overhead durch TCP und TLS, der eine Namensauflösung deutlich einbremst. Dies ist allerdings nicht so tragisch, da zum einen geöffnete DoT-Verbindungen für mehrere DNS-Abfragen verwendet werden und zum anderen einige Performance-Optimierungen mit der neuen TLS-Version 1.3 auf den Weg gebracht wurden.

DoT kann ohne Probleme bereits heute genutzt werden. Bei den Betriebssystemen wird das Protokoll ab Android 9 (Pie) unterstützt (siehe Screenshot). Zu finden ist die Option in den Einstellungen unter “Netzwerk & Internet” unter dem Punkt “Privates DNS”. Bei der Option “Automatisch” testet Android, ob der Nameserver DoT anbietet und verwendet es gegebenenfalls. Darüber hinaus kann ab Version 239 des DNS-Resolvers in Linux-Systemd (systemd-resolved) DoT genutzt werden, welches allerdings standardmäßig deaktiviert ist.

Ebenso existieren bereits eine Vielzahl an DNS-Resolvern. Eine gute Übersicht bekannter DoT-Server findet ihr hier beim DNS Privacy Project.

Wenn ihr eure Surf-Gewohnheiten nicht mit großen amerikanischen Konzernen teilen wollt (Google, Cloudflare, usw.), existiert hier eine zweite Liste mit kleineren DoT-Servern und „no logging“-Policy. Einige davon stehen in Deutschland und bieten zusätzlich eine Blockierung von Werbung und Trackern. Empfehlen kann ich euch das Projekt Blahdns.

DNS over HTTPS (DoH)

Auf den ersten Blick scheint DoH (RFC 8484) eine gewisse Ähnlichkeit mit DoT zu haben. Auch hier kommt eine TCP-Verbindung mit TLS zum Einsatz, um Lauscher das Leben schwer zu machen. Der Unterschied ist, dass die DNS-Informationen zusätzlich im HTTPS-Protokoll verpackt sind.  Wie bei DoT erfolgt bei DoH keine Validierung der DNS-Daten, weshalb DNSSEC auch hier in Kombination verwendet werden sollte.

DoH wurde in nur wenigen Monaten durch die IETF-Gremien gepeitscht. Als treibende Kräfte hinter DoH stecken unter anderem Mozilla und Google. Kein Wunder, denn DoH ist im Vergleich zu herkömmliches DNS und DoT (beide auf Systemebene) auf Anwendungsebene umgesetzt und steckt damit direkt im Browser. Die DNS-Kommunikation erfolgt via HTTPS zwischen Browser und Webserver. Stichwort HTTPS: Was zunächst als nebensächlich erscheint, könnte in der Praxis gravierende Auswirkungen haben und die bewährte Infrastruktur großflächig umkrempeln.

Theoretisch könnte bei DoH jeder Webserver als DNS-Resolver fungieren. Die ursprüngliche Idee dahinter ist, dass ein Webserver direkt alle für den Webseitenaufbau benötigten IP-Adressen mitliefert und nicht wie bisher, diverse einzelne DNS-Anfragen gestellt werden müssen. Selbst bei komplexen Webseiten wäre nur noch eine einzige DNS-Anfrage notwendig. Allerdings würde dieses Verhalten Tür und Tor für Malware und Phisher öffnen. Webseiten können dir ohne Probleme Antworten für Dritte unterschieben, Stichwort Out-Of-Bailiwick.

Eine weitere Konsequenz ist, dass über DoH-fähige Webserver beliebige DNS-Daten angefragt werden können. Dieser Traffic lässt sich von normalem Web-Traffic nicht mehr unterscheiden und lässt sich im Gegensatz zu DoT praktisch nicht blockieren. Des Weiteren wäre damit auch die Gefahr einer DNS-basierten Zensur gebannt. Wenn jeder Webserver DNS-Daten liefern kann, wäre eine Zensur schlicht und ergreifend aussichtslos. Gleichzeitig könnte die Namensauflösung via DoH dezentral über viele Webserver erfolgen, was automatisch die Privatsphäre stärkt.

Die zuletzt genannten Punkte sind aktuell aber eher Wunschdenken. Die Realität sieht so aus, dass Mozilla und Google in ihren Browsern zwar DoH implementiert haben, die Namensauflösung aber über einen zentralen Server erfolgt. Anstatt einem unabhängigen dezentralen DNS-Verkehr haben wir Stand heute eine ungesunde Zentralisierung bei amerikanischen Großkonzernen, die dann sämtliche Webseiten sehen würden, welche im Browser aufgerufen werden. Was das für die Privatsphäre bedeutet, könnt ihr euch selber ausmalen. Davon abgesehen wären diese zentralen DNS-Knoten dann geradezu prädestiniert für einen staatlichen Lauschangriff.

Ein weiteres Problem könnte sich in größeren Unternehmen ergeben. Mit DoH werden die internen DNS-Resolver umgangen und interne Dienste könnten somit nicht mehr erreichbar sein. Auch die Administrierbarkeit und Fehlersuche gestaltet sich deutlich schwieriger bis unmöglich, wenn zukünftig in jeder Anwendung unterschiedliche DNS-Resolver zum Einsatz kommen.

Eine Liste von verfügbaren DNS-Servern findet ihr beim DNS Privacy Project oder hier bei Github.

Fazit

Zusammengefasst muss ich sagen, dass der Hype um DoT und DoH nicht ganz gerechtfertigt ist. Beide Protokolle verfügen über gewisse Nachteile und sind nicht uneingeschränkt zu empfehlen. Jedem sollte bewusst sein, dass die Absicherung der “letzten Meile” ohne DNSSEC sinnlos ist. DoT und DoH sichern die Verbindung zum DNS-Resolver ab. DNSSEC kümmert sich um die Validierung der erhaltenen DNS-Daten.

Was bedeutet dies nun in der Praxis? Wie so oft wird es keine Lösung geben, die alle problematischen Punkte komplett beseitigt. Ich unterstütze allerdings die Meinung, dass herkömmliches DNS durch seine Dezentralität prinzipiell besser dazu geeignet ist, die Privatsphäre zu schützen. Zentrale DoT- bzw. DoH-Server in den Händen großer Unternehmen bewirken eher das Gegenteil.

Ein möglicher Ansatz wäre die Verwendung eines DNS-Resolvers mit DNSSEC-Unterstützung und eine lokale Kopie der Root-Zone. Diese Anforderungen lassen sich zum Beispiel mit einem Raspberry Pi und Unbound als DNS-Resolver in Kombination mit Hyperlocal umsetzen. Nachteil ist die fehlende Verschlüsselung, was jedoch verschmerzbar ist, da durch Caching und Zonentransfer DNS-Anfragen in vielen Fällen erst gar nicht gestellt werden. Wenn sich ein Lauscher im lokalen Netz bzw. innerhalb der “letzten Meile” befindet, ist DNS vermutlich eines der kleineren Probleme.

Ein anderer Ansatz wäre DNSSEC in Kombination mit DoT. Dabei sollten allerdings möglichst viele DNS-Resolver verwendet werden, sodass die Anfragen auf verschiedene DoT-Server verteilt werden. Damit wird das Erstellen von Profilen erschwert und man könnte sogar die Nutzung  von Google, Cloudflare und Co in Erwägung ziehen.

User Profile Wizard: Lokales Windows-Benutzerprofil zu Domäne migrieren

Mit dem Tool User Profile Wizard von ForensiT lassen sich lokale Benutzerprofile unter Windows mit wenigen Klicks zu einer Domäne migrieren. Des Weiteren ist mit dem Tool auch die Übernahme von Benutzerprofilen von einer Domäne zu einer anderen möglich.

Ich habe das Tool vor zig Jahren das erste Mal erfolgreich eingesetzt. Erst kürzlich hatte ich es erneut gebraucht, jedoch erst nach längerer Suche wiedergefunden. Wie bei der ersten Nutzung konnte ich damit einige lokale Windows-Profile blitzschnell und ohne Probleme in ein Domänenprofil umwandeln. Der große Vorteil ist, dass sämtliche Daten, Programme und Einstellungen erhalten bleiben.

User Profile Wizard ist unter Windows 7, Windows 8(.1) und Windows 10 funktionstüchtig. Folgende Schritte sind zur Migration eines Userprofils notwendig.

  1. User Profile Wizard mit Adminrechten starten und Willkommens-Dialog bestätigen
  2. Das gewünschte Benutzerprofil markieren und auf “Weiter” klicken, die weiteren Optionen zur Deaktivierung bzw. Löschung des lokalen Profils würde ich zur Sicherheit nach erfolgreicher Migration von Hand vornehmen.
  3. Die neue Domäne und den Domänenuser eintragen und sicherstellen, dass der Punkt “Join Domain” aktiviert ist
  4. Jetzt müsst ihr lediglich noch die Anmeldedaten des Domänen-Benutzers eingeben und die Migration des Benutzerprofils startet.
  5. Nach kurzer Zeit ist der Vorgang beendet. Mit einem Neustart werden alle Änderungen aktiv.

Neben der Personal-Edition existieren zwei weitere, kostenpflichtige Versionen (Professional Edition und Corporate Edition) mit einem größeren Funktionsumfang. Eine Vergleichstabelle liefert eine detaillierte Auflistung der Unterschiede. Größtenteils handelt es sich aber um Automatisierungsfunktionen, die erst bei einer größeren Menge von umzustellenden Profilen wichtig sind. Für einige wenige Profile seid ihr mit der Personal-Edition bestens gerüstet!

Infos zum Microsoft Dezember-Patchday 2019

Der letzte Microsoft-Patchday im Jahr 2019 fällt relativ klein aus, behebt allerdings dennoch einige kritische Sicherheitslücken. Neben fast allen Microsoft-Betriebssystemen bekommen auch der Internet Explorer, Microsoft SQL Server, Visual Studio und Microsoft Office Sicherheitsupdates.

Produktfamilie Maximaler Schweregrad
Maximale Auswirkung Zugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1909, Version 1903, Version 1809, Version 1803, Version 1709 Kritisch Remotecodeausführung Windows 10, Version 1909, und Windows 10, Version 1903: 4530684; Windows 10, Version 1809: 4530715; Windows 10, Version 1803: 4530717; Windows 10, Version 1709: 4530714
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1909, Version 1903 und Version 1803) Kritisch Remotecodeausführung Windows Server, Version 1909, und Windows Server, Version 1903: 4530684; Windows Server 2019: 4530715; Windows Server 2016: 4530689; Windows Server, Version 1803: 4530717
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008 Kritisch Remotecodeausführung Monatlicher Rollup für Windows 8.1, Windows Server 2012 R2 und Windows RT 8.1: 4530702; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4530730; monatlicher Rollup für Windows Server 2012: 4530691; reines Sicherheitsupdate für Windows Server 2012: 4530698; monatlicher Rollup für Windows 7 und Windows Server 2008 R2: 4530734; reines Sicherheitsupdate für Windows 7 und Windows Server 2008 R2: 4530692; monatlicher Rollup für Windows Server 2008: 4530695; reines Sicherheitsupdate für Windows Server 2008: 4530719
Internet Explorer Hoch Remotecodeausführung Kumulatives Update für Internet Explorer: 4530677;
Software im Zusammenhang mit Microsoft Office Hoch Remotecodeausführung KB-Artikel im Zusammenhang mit Office: 4484180, 4484193, 4484186, 4484169, 4475598, 4475601, 4484094, 4461590, 4484166, 4461613, 4484179, 4484182, 4484196, 4484190, 4484192, 4484184
Visual Studio Kritisch Remotecodeausführung Weitere Informationen siehe den Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdateguide
Software im Zusammenhang mit SQL Server Hoch Spoofing Weitere Informationen siehe den Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdateguide
Microsoft Authentication Library (MSAL) für Android Hoch Veröffentlichung von Informationen https://github.com/AzureAD/microsoft-authentication-library-common-for-android

Beginnend mit April 2017 hat Microsoft die bisher verwendeten Sicherheitsbulletin-Webseiten durch den Leitfaden für Sicherheitsupdates ersetzt. Das neue Portal soll durch die vielfältigen Such- und Filterfunktionen einen besseren Überblick über neue Updates bieten.

Für jede Windows 10 Version veröffentlicht Microsoft ein eigenes kumulatives Update, welche die entsprechenden Windows 10 Versionen auf neue Build-Nummern hebt:

  • Windows 10 Version 1909 Build 18363.535
  • Windows 10 Version 1903 Build 18362.535
  • Windows 10 Version 1809 Build 17763.914
  • Windows 10 Version 1803 Build 17134.1184
  • Windows 10 Version 1709 Build 16299.1565
  • Windows 10 Version 1607 Build 14393.3384
  • Windows 10 Version 1507 (RTM) Build 10240.18427

VPN-Installation über den privaten Internetrouter

Ganz unabhängig davon, ob Sie privat unterwegs sind oder für ein Unternehmen im Außendienst arbeiten, die Sicherheit Ihrer Daten hat für Sie sicherlich die höchste Priorität. Oftmals wird diese begleitet von dem Wunsch, von überall aus ins Internet zu gehen – selbst wenn der Zugriff zum Internet nicht abgesichert ist und es durchaus passieren kann, dass die Daten, die über eben dieses ungesicherte Netz übertragen werden, während der Übertragung korrumpiert werden könnten.

Um das Risiko des Hackings der Daten ausschließen zu können, sollten Sie ein „Virtuelles Privates Netzwerk“ bzw. englisch „Virtual Private Network“ (VPN) einrichten. Dabei handelt es sich um ein in sich geschlossenes Netzwerk, zu dem lediglich bestimmte Personen Zugriff erhalten, beispielsweise Außendienstmitarbeiter oder Handelsvertreter. Aber auch Privatleute nutzen die Qualitäten des VPNs immer häufiger, in dem sie ihr eigenes Heimnetzwerk besonders schützen. Dazu wird eine VPN-Software auf den Client – zumeist ein Smartphone oder Tablet – aufgespielt und darüber mit dem VPN-Server des Anbieters verbunden. Zwischen beiden Geräten wird ein VPN-Tunnel zum sicheren Datentransfer aufgebaut, durch den die Daten verschlüsselt gesendet werden und von außen nicht einsehbar sind. Parallel dazu wird die IP-Adresse des Clients durch die des VPN-Servers ersetzt, sodass eine Zuordnung des Datenzugriffs nicht mehr nachvollziehbar ist.

Vorrangig wird ein VPN eingesetzt, um anonym auf Internetinhalte zugreifen zu können und die eigene Privatsphäre zu schützen. Da der Transfer aller Daten verschlüsselt erfolgt, lassen sich Versender und Empfänger nur sehr schwierig zurückverfolgen.

Die eigene Fritzbox zum VPN-Tunnel umfunktionieren

AVM FRITZ!Box 7490

AVM FRITZ!Box 7490

Für Privatleute, die eine FritzBox des Herstellers AVM im Einsatz haben, können gleich mehrfach durch den Umbau zu einem VPN-Server profitieren. Um die FritzBox für das VPN einzurichten, müssen Sie die folgenden Schritte durchführen:

  1. Aktivieren Sie per Klick auf die Punkte rechts oben die „Erweiterte Ansicht“.
  2. Klicken Sie auf „Internet“ und auf Ihr „MyFRITZ!-Konto“.
  3. Existiert ein „MyFRITZ!-Konto“ bereits, geht es mit Schritt 11 weiter. Sonst wählen Sie „Neues MyFRITZ!-Konto erstellen“, geben Sie Ihre E-Mail-Adresse ein und gehen Sie auf „Weiter“.
  4. AVM sendet Ihnen nun eine E-Mail. In ihr ist ein Link enthalten, um Ihre „FritzBox! Registrieren“ und auf der folgenden Webseite auf „MyFRITZ!-Konto einrichten“.
  5. Geben Sie auf den Feldern „Kennwort“ und „Kennwort bestätigen“ ein neues, noch nicht gebrauchtes Kennwort ein.
  6. Klicken Sie auf „Vorgang abschließen“.
  7. Gehen Sie zurück zur FritzBox und klicken Sie dort auf „MyFRITZ!-Internetzugriff einrichten“ und „FRITZ!Box-Benutzer einrichten“. War MyFRITZ bereits eingerichtet, klicken Sie im „System“ auf „FRITZ!Box-Benutzer“.
  8. Nun können Sie alle Benutzer einrichten, die später Zugriff auf den FritzBox-VPN-Server erhalten sollen. Jeder Besucher ist mit Benutzername und einem einzigartigen Passwort einzurichten. Besteht schon ein FritzBox-Benutzer für den Zugriff, aktivieren Sie den Stift daneben.
  9. Stellen Sie sicher, dass sowohl die Option „Zugang aus dem Internet erlaubt“ als auch die Option „VPN“ aktiviert sind.
  10. Die E-Mail-Adresse bleibt unverändert und klicken Sie auf „OK“.
  11. Die FRITZ!Box meldet sich nun automatisch bei MyFRITZ! an. Der Hinweis „Ihre FRITZBox ist bei MyFRITZ! angemeldet“, eventuell unter der Option Internet oder im MyFritz!-Konto.
  12. Notieren Sie sich die Zeichenfolge bei „(Ihrer) MyFRITZ!-Adresse“.
  13. Klicken Sie auf „Heimnetz“, „Netzwerk“, „Netzwerkeinstellungen“ und „IPv4-Adressen“.
  14. Stellen Sie sicher, dass bei der „IPv4-Adressen“ nicht die Standardadresse 192.168.178.0 steht, sondern tragen Sie stattdessen eine Alternative wie 192.168.178.1 ein und klicken anschließend auf OK.
  15. Warten Sie, bis sich der PC wieder mit der FritzBox verbunden hat.

Fernzugriff auf die eigene FritzBox

Die FritzBox von AVM bieten eine unvergleichliche Funktionsvielfalt und ermöglichen es zusätzlich, dass für einen sicheren Fernzugriff auf das Heimnetzwerk, beispielsweise, wenn ein Familienmitglied unterwegs und die Wahrscheinlichkeit eines Zugriffs über eine ungesicherte WLAN-Schnittstelle hoch ist. Neben den oben genannten Einstellungen am Router selbst müssen auch Änderungen an den digitalen Endgeräten vorgenommen werden, wobei die Art des Gerätes und die Software eine Rolle spielt.

Kategorien: Internet Tutorials

Raspberry Pi – SSH Hardening

Raspberry Pi Logo

Die wohl am häufigsten genutzte Methode zur Administration eines Raspberry Pis ist Secure Shell (SSH). In den aktuellen Raspbian Versionen ist SSH bereits integriert und muss lediglich aktiviert werden.

Im aktuellen Raspbian Buster (basiert auf Debian 10 Stable) kommt OpenSSH in Version 7.9p1 zum Einsatz. Die Standard-Konfiguration ist in puncto Sicherheit zwar in Ordnung, aber mit einigen Handgriffen lässt sich die Administrationsschnittstelle deutlich besser absichern. Damit steigt die Hürde für potenzielle Angreifer deutlich. Dies ist vor allem wichtig, wenn euer Pi aus dem Internet erreichbar ist.

Mein Artikel bezieht sich auf Raspbian Buster mit OpenSSH 7.9, ist aber größtenteils auch für andere Distributionen und OpenSSH-Versionen anwendbar.

Grundlagen und hilfreiche Befehle

OpenSSH besteht aus zwei Teilen: Dem Server Daemon (sshd) und dem Client (ssh). In diesem Tutorial widme ich mich ausschließlich sshd. Die Konfigurationsdatei des Servers befindet sich hier:

/etc/ssh/sshd_config

Der Status des sshd-Daemons kann mit folgendem Befehl abgefragt werden:

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-02 08:44:33 GMT; 2 weeks 3 days ago

Damit könnt ihr sicherstellen, dass sshd automatisch startet (enabled) und gerade läuft (active (running)). Des Weiteren seht ihr auch die 10 letzten Logeinträge.

Mit folgendem Befehl könnt ihr die aktiven SSH-Sessions einsehen:

ss -n -o state established '( dport = :22 or sport = :22 )'

Bei Änderungen an der Server-Konfiguration empfehle ich diese vor dem Neustart des Dienstes zu prüfen. Damit könnt ihr Syntaxfehler und Probleme mit ungültigen Einstellungen in “/etc/ssh/sshd_config” verhindern:

sudo sshd -t

Zum Anwenden der Änderungen empfehle ich sshd folgendermaßen neuzustarten. Mit dieser Variante besteht die größte Chance, dass offene Remote-Sessions nicht geschlossen werden.

sudo systemctl reload ssh.service

SSH-Server: Einstellungen

Wie oben bereits erwähnt lassen sich die Einstellungen in der Datei “/etc/ssh/sshd_config” anpassen und sind nach einem Neustart von sshd aktiv. Einige Einstellungen sind bereits standardmäßig deaktiviert. Diese sind in der Config-Datei auskommentiert. Es schadet jedoch nicht diese noch einmal zu überprüfen.
Über die Protokoll-Version müssen wir uns keine Sorgen machen, da ab OpenSSH 7.0 SSH Version  1 bereits beim Kompilieren deaktiviert wird.
Standardmäßig hört der Server auf Port 22. Dieser kann geändert werden, um beispielsweise die Anzahl der Angriffe zu verringern. Einen Sicherheitsgewinn gibt es meiner Meinung nach nicht.
Wenn der Server mehrere IP-Adressen besitzt, kann über “ListenAdress” eingeschränkt werden, auf welcher IP eine Verbindung akzeptiert werden soll.

Port22
ListenAddress 192.168.10.10
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktivieren. Davon abgesehen wird vom Server ein Rückkanal zum Client geöffnet, was sicherheitstechnisch nicht ganz unbedenklich ist.

X11Forwarding no

Mittels .rhosts-Datei kann der Zugriff von fremden Systemen lediglich anhand der IP-Adresse erlaubt werden. Dieser Zugriff ist heutzutage nicht mehr üblich und daher standardmäßig deaktiviert.

IgnoreRhosts yes

Useraccounts ohne Passwort dürfen sich nicht via SSH anmelden. Auch diese Option ist per Default deaktiviert.

PermitEmptyPasswords no

Eine direkte Anmeldung mit dem Account “root” sollte in der Regel nicht erlaubt werden (PermitRootLogin no). Falls dies aus bestimmten Gründen dennoch notwendig sein sollte, ist die Option “prohibit-password” in Ordnung. Diese ist standardmäßig gesetzt und erlaubt nur eine Public-Key-Authentifizierung mit dem root Account.

PermitRootLogin prohibit-password

Die maximale Zahl der Anmeldeversuche pro User sind standardmäßig auf 6 gesetzt. Ich würde empfehlen den Wert weiter zu verringern, beispielsweise auf 3.

MaxAuthTries 3

Inaktive Sessions können nach einer bestimmten Zeit automatisch beendet werden. Mit “ClientAliveInterval” wird festgelegt, nach wie vielen Sekunden Inaktivität der Server eine Nachricht an den Client sendet. “ClientAliveCountMax” ist die Anzahl, wie oft dies der Server wiederholt, bis der Client getrennt wird. In meinem Beispiel oben wird der Client nach 15 Minuten getrennt.

ClientAliveInterval 300
ClientAliveCountMax 3

Normalerweise erfolgt die Anmeldung am Server mit Username und Passwort. Eine bessere Alternative ist die Public-Key-Authentifizierung. Diese ist bereits standardmäßig erlaubt.

PubkeyAuthentication yes

Zur Einrichtung muss auf dem Client zunächst ein neues Schlüsselpaar generiert werden. Wählt hier “Ed25519”, sofern nichts gravierendes dagegenspricht. Unter Windows könnt ihr dies prima mit PuTTYGen erledigen. Ab Windows 10 1809 kann dies auch direkt via PowerShell oder der Eingabeaufforderung erledigt werden. Unter Linux nutzt ihr ssh-keygen. Der Einsatz einer Passphrase ist zwar optional, aber ich empfehle ein starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Im nächsten Schritt muss der Public Key auf dem Server eingetragen werden. PuTTYGen stellt euch den String bereit, den ihr in die “authorized_keys” kopieren müsst.

ssh pi@192.168.10.10
mkdir ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Linux geht dies mit “ssh-copy-id” etwas einfacher.

ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@192.168.10.10

Abschließend solltet ihr prüfen, ob die Anmeldung via Public-Key-Authentifizierung funktioniert. Falls ja, könnt ihr nun die Passwort-Anmeldung an eurem SSH-Server deaktivieren.

PasswordAuthentication no
ChallengeResponseAuthentication no

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Zur Prüfung, welche Cipher-Suites und Verschlüsselungsalgorithmen euer OpenSSH-Server anbietet, eignet sich das Python-Script “ssh-audit”:

cd ~
wget https://github.com/jtesta/ssh-audit/releases/download/v2.4.0/ssh-audit-2.4.0.tar.gz
tar -xvzf ssh-audit-2.4.0.tar.gz
~/ssh-audit-2.4.0/ssh-audit.py 192.168.10.10

Alternativ könnt ihr auch Nmap dazu verwenden:

nmap -p22 -n -sV --script ssh2-enum-algos 192.168.10.10

Schauen wir uns zunächst die Algorithmen für den Schlüsseltausch an. Falls Curve25519 nicht ausreichend ist, könnt ihr noch “diffie-hellman-group-exchange-sha256” hinzufügen.

# Allow only secure key exchange algorithms
KexAlgorithms curve25519-sha256@libssh.org

Danach folgen die Schlüssel bzw. Algorithmen für die Authentifizierung. Hier solltet ihr alle vorhandenen Host-Schlüssel löschen und neu generieren.

cd /etc/ssh
sudo rm ssh_host_*key*
sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Anschließend könnt ihr in eure “sshd_config” folgendes eintragen:

# Allow only secure server authentication algorithms
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519,ssh-rsa

Als nächstes nehmen wir uns den symmetrischen kryptographischen (Ciphers) sowie MAC (Message Authentication Code) Algorithmen an. Folgendes gilt aktuell als sicher:

# Allow only secure symmetric ciphers
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# Allow only secure message authentication codes
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Prüft zur Sicherheit, dass ihr vor dem Neustart von sshd eine Verbindung habt, damit ihr euch im Notfall nicht den Zugang zu eurem Raspberry absägt.

Einen guten Artikel mit weiteren Details über die einzelnen Cipher-Suites und Verschlüsselungsalgorithmen findet ihr hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Infos zum Microsoft November-Patchday 2019

Microsoft Logo

Der Microsoft-Patchday im November 2019 behebt wie immer eine Vielzahl kritischer Sicherheitslücken. Neben fast allen Microsoft-Betriebssystemen sind davon auch der Internet Explorer, Microsoft Exchange Server und ChakraCore betroffen. Andere Bugfixes für Office, SharePoint, Visual Studio und Azure Stack werden lediglich als “hoch” eingestuft.

Produktfamilie Maximaler Schweregrad
Maximale Auswirkung Zugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1903, Version 1809, Version 1803, Version 1709 Kritisch Remotecodeausführung Windows 10, Version 1903: 4524570; Windows 10, Version 1809: 4523205; Windows 10, Version 1803: 4525237; Windows 10, Version 1709: 4525241
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1903 und Version 1803) Kritisch Remotecodeausführung Windows Server 2019: 4523205; Windows Server 2016: 4525236; Windows Server, Version 1903: 4524570; Windows Server, Version 1803: 4525237
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008 Kritisch Remotecodeausführung Windows 8.1, Windows Server 2012 R2: 4525243 und 4525250; Windows Server 2012: 4525246 und 4525253; Windows 7 und Windows Server 2008 R2: 4525235 und 4525233; Windows Server 2008: 4525234 und 4525239
Internet Explorer Kritisch Remotecodeausführung Kumulatives Update für Internet Explorer: 4525106. Updates für Internet Explorer sind auch in Updatepaketen für die oben aufgelisteten Windows-Versionen enthalten.
Software im Zusammenhang mit Microsoft Office Hoch Remotecodeausführung Supportartikel zu Updates für Microsoft Office: 4484113, 4484119, 4484127, 4484141, 4484144, 4484148, 4484152, 4484158, 4484159, 4484160, 4484164.
Software im Zusammenhang mit Microsoft SharePoint Hoch Veröffentlichung von Informationen Supportartikel zu Updates für Microsoft SharePoint: 4484142, 4484143, 4484149, 4484151, 4484157, 4484165
Visual Studio Hoch Rechteerweiterungen Visual Studio 2017, Version 15.9: http://aka.ms/vs/15/release/latest
Visual Studio 2019, Version 16.0: https://my.visualstudio.com/Downloads/
Visual Studio 2019, Version 16.3: https://my.visualstudio.com/Downloads/
Microsoft Exchange Server Kritisch Remotecodeausführung Supportartikel zu Updates für Microsoft Exchange Server: 4523171
ChakraCore Kritisch Remotecodeausführung Weitere Informationen finden Sie unter https://github.com/Microsoft/ChakraCore/wiki
und https://github.com/Microsoft/ChakraCore/releases/
Azure Stack Hoch Spoofing https://docs.microsoft.com/de-de/azure-stack/operator/release-notes-security-updates?view=azs-1910

Beginnend mit April 2017 hat Microsoft die bisher verwendeten Sicherheitsbulletin-Webseiten durch den Leitfaden für Sicherheitsupdates ersetzt. Das neue Portal soll durch die vielfältigen Such- und Filterfunktionen einen besseren Überblick über neue Updates bieten.

Für jede Windows 10 Version veröffentlicht Microsoft ein eigenes kumulatives Update, welche die entsprechenden Windows 10 Versionen auf neue Build-Nummern hebt:

  • Windows 10 Version 1909 Build 18363.476
  • Windows 10 Version 1903 Build 18362.476
  • Windows 10 Version 1809 Build 17763.864
  • Windows 10 Version 1803 Build 17134.1130
  • Windows 10 Version 1709 Build 16299.1508
  • Windows 10 Version 1607 Build 14393.3326
  • Windows 10 Version 1507 (RTM) Build 10240.18395

„www“ und „https://“ in Chrome-Adresszeile ab Chrome 78

Google Chrome Logo
Ab Chrome 83 funktioniert die Wiederherstellung der vollständigen URL so: https://www.antary.de/2020/06/07/www-und-https-in-chrome-adresszeile-ab-chrome-83/

Ab Chrome 76 werden Internet-Adressen in der Adresszeile standardmäßig ohne „https://“ und „www“ angezeigt. In meinem Artikel “„www“ und „https://“ in Chrome-Adresszeile anzeigen” habe ich euch gezeigt, wie ihr das Verhalten anpassen könnt, damit diese meiner Meinung nach wichtigen URL-Bestandteile wieder angezeigt werden.

Mit der kürzlich veröffentlichten Version 78 hat Google diesbezüglich im Chrome abermals eine Änderung durchgeführt. Der relativ einfache Workaround über “chrome://flags/” funktioniert damit leider nicht mehr. Die entsprechenden Optionen (siehe Screenshot) sind schlicht und einfach nicht mehr vorhanden.

Wer die Flags vor Chrome 78 gesetzt hat, kommt weiterhin in den Genuss der vollen URL.

Ab Chrome 78 müssen die drei Flags von Hand in der “Local State” Datei eingepflegt werden. Dafür muss Chrome zunächst komplett beendet werden. Anschließend diese Datei mit einem Texteditor öffnen, sie befindet sich unter folgendem Pfad:

C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data\

Dort muss folgendes eingetragen werden.

{
	"browser": {
		"enabled_labs_experiments": [
			"omnibox-ui-hide-steady-state-url-scheme@2",
			"omnibox-ui-hide-steady-state-url-trivial-subdomains@2",
			"omnibox-ui-hide-steady-state-url-path-query-and-ref@2"
		]
	}, ... ...
}

Vermutlich sind bei euch schon diverse andere Einstellungen vorhanden. In diesem Fall müsst ihr die drei Optionen von Hand an der richtigen Stelle einfügen. Achtet dabei streng auf die Einhaltung der Syntax.

Zum Schluss die Datei speichern und Chrome starten. Wenn alles geklappt hat, solltet ihr nun die volle URL sehen können (siehe Screenshot).

Wenn es nicht funktioniert, habt ihr höchstwahrscheinlich bei der Syntax einen Fehler gemacht und Chrome kann die Datei “Local State” nicht lesen. In diesem Fall wird die alte Datei in “Local State.bad” umbenannt und eine neue “Local State”-Datei generiert. Dann einfach nochmal die Syntax prüfen und den Fehler beheben.

Kategorien: Software & Apps

Cisco und der Verpackungswahn

Cisco Logo

Cisco bietet die Möglichkeit nur wenige Monate oder Wochen benutzte Hardware zu signifikant günstigeren Preisen zu erwerben. Diese Cisco Refresh Produkte sind generalüberholt, vollständig zertifiziert und von neuer Hardware quasi nicht zu unterscheiden. Auch bei der Garantie und Lizenzierung gibt es keine Nachteile. Gute Gründe, um bei Neuanschaffungen über entsprechende Produkte nachzudenken.

Anhand einiger SFP-Module (GLC-LH-SMD), die via Cisco Refresh bezogen wurden, möchte ich euch gerne den Verpackungswahn bei Cisco zeigen. Die SFPs werden einzeln verpackt geliefert. Im größeren Karton befindet sich zunächst ein kleinerer Karton. Dort ist das Modul in einer antistatischen Verpackung enthalten. Das letzte Bild zeigt 20 ausgepackte SFPs und den entstandenen Kartonabfall. Den Plastikabfall habe ich dabei noch gar nicht berücksichtigt.

Ich stelle mir gerade vor, wie viel Verpackungs- und Transportkosten sich einsparen ließen. Geschweige denn von der unnötig verbrauchten Arbeitszeit während dem Auspacken ;-)

Warum NordVPN unseriös ist & Hack

NordVPN ist ein VPN-Anbieter, der vor allem in den letzten Monaten durch Werbung und Kooperation mit Influencern stark an Bekanntheit gewonnen hat. Unter anderem tritt man als Sponsor bei der deutschen Übertragung der derzeit laufenden League of Legends WM 2019 auf. Hier wird folgender Werbespot ausgestrahlt.

https://www.youtube.com/watch?v=CeKGfaxsC4Q

NordVPN richtet sich mit dem Video direkt an die Zielgruppe der Gamer. Mit fiktiven Szenarien wie Phishing-Links, Malware oder einer Botnet-Attacke wird versucht Angst zu erzeugen um dann das eigene Produkt als Lösung vorzustellen: “NordVPN schützt deinen Traffic mit der modernsten Verschlüsselung”.

Wer sich ein bisschen mit der Materie auskennt weiß sofort, dass die Aussagen irreführend sind und falsche Versprechungen liefern. Ich gehe sogar weiter und behaupte, dass dies schon mit einer Täuschung von Unwissenden gleichzusetzen ist. Eine VPN-Verbindung schützt nicht vor Phishing-Links und schon gar nicht vor Malware.

Des Weiteren wirbt NordVPN auf der Webseite mit “absoluter Privatsphäre”, was alleine betrachtet schon extrem unseriös ist. Für weitere Infos empfehle ich euch den Artikel “Anonymität: Die haltlosen Werbeversprechen der VPN-Anbieter” von Mike Kuketz.

Weitere Punkte welche die Unseriösität von NordVPN unterstreichen:

Alles in allem habe ich euch hoffentlich genügend Gründe geliefert, um die Finger von NordVPN zu lassen. Falls ihr noch nicht ganz überzeugt seid, wäre noch der Hack zu erwähnen.

NordVPN wurde gehackt

Vor wenigen Tagen wurden Informationen über Konfigurationsdateien und private Schlüssel von NordVPN geleaked. Kurz darauf hat sich der Anbieter zu Wort gemeldet und die Hacker-Attacke bestätigt.

Von den drei privaten Schlüsseln gehörte einer zu einem inzwischen abgelaufenen Webseiten-Zertifikat. Die zwei anderen Schlüssel gehörten zu einer OpenVPN-Konfiguration. Die Angreifer hätten somit signierte Webseiten erstellen oder sich als Man in the Middle in vermeintlich sicheren VPN-Traffic einklinken können. Ob das passiert ist, lässt sich höchstwahrscheinlich nicht mehr nachvollziehen. Laut NordVPN geschah der Hacker-Angriff im März 2018 über ein unsicheres Remote-Management-System. Die geleakten Schlüssel sollen zu diesem Zeitpunkt bereits ungültig gewesen sein und Kundendaten waren nicht gefährdet.

Da sich NordVPN aber erst nach dem Leak gemeldet und nicht proaktiv reagiert hat, bleiben auf jeden Fall größere Zweifel offen.

Kategorien: Internet

Microsoft kündigt End of life für MDOP an

Microsoft Logo

Im September hat Microsoft das End of life Datum für das Microsoft Desktop Optimization Pack (MDOP) bekannt gegeben.

MDOP ist eine Sammlung von verschiedenen Tools, die das Client-Management vereinfachen soll. Neben Sicherheitswerkzeugen sind auch Tools für die Virtualisierung und das Management vorhanden. Insgesamt besteht MDOP aus den folgenden sechs Tools:

  • Microsoft Advanced Group Policy Management (AGPM)
  • Microsoft Application Virtualization (App-V)
  • Microsoft Diagnostics and Recovery Toolset (DaRT)
  • Microsoft BitLocker Administration and Monitoring (MBAM)
  • Microsoft Enterprise Desktop Virtualization (MED-V)
  • Microsoft User Experience Virtualization (UE-V)

Jedes dieser Produkte wurde separat erstellt und später unter dem MDOP zusammengefasst. Aus diesem Grund hatte jedes Tool bisher auch seinen eigenen Support-Lebenszyklus. Mit der EOL-Ankündigung hat Microsoft ein einheitliches Enddatum für den Support aller Tools festgelegt: Am 14. April 2026 ist Schluss mit Support. Weitere Details dazu finden sich im Beitrag der Microsoft Tech Community.

Kategorien: Windows Windows 10

Infos zum Microsoft Oktober-Patchday 2019

Microsoft Logo

Der Microsoft-Patchday im Oktober 2019 behebt wie immer eine Vielzahl kritischer Sicherheitslücken. Neben fast allen Microsoft-Betriebssystemen sind davon auch der Internet Explorer, Azure App Service in Azure Stack und ChakraCore betroffen. Andere Bugfixes unter anderem für Office, SharePoint, SQL Server Management Studio und Microsoft Dynamics 365 werden lediglich als “hoch” eingestuft.

Produktfamilie Maximaler Schweregrad
Maximale Auswirkung Zugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1903, Version 1809, Version 1803, Version 1709, Version 1703 Kritisch Remotecodeausführung Sicherheitsupdate für Windows 10, Version 1903: 4517389; Sicherheitsupdate für Windows 10, Version 1809: 4519338; Sicherheitsupdate für Windows 10, Version 1803: 4520008; Sicherheitsupdate für Windows 10, Version 1709: 4520004; Sicherheitsupdate für Windows 10, Version 1703: 4520010
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1903 und Version 1803) Kritisch Remotecodeausführung Windows Server, Version 1903: 4517389; Windows Server 2019: 4519338; Windows Server 2016: 4519998; Windows Server, Version 1803: 4520008
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008 Kritisch Remotecodeausführung Monatlicher Rollup für Windows 8.1, Windows Server 2012 R2 und Windows RT 8.1: 4520005; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4519990; reines Sicherheitsupdate für Windows Server 2012: 4519985; monatlicher Rollup für Windows Server 2012: 4520007; monatlicher Rollup für Windows 7 und Windows Server 2008 R2: 4519976; monatlicher Rollup für Windows Server 2008: 4520002; reines Sicherheitsupdate für Windows Server 2008: 4520009
Internet Explorer Kritisch Remotecodeausführung Kumulatives Update für Internet Explorer: 4519974. Updates für Internet Explorer sind auch in Updatepaketen für die oben aufgelisteten Windows-Versionen enthalten.
Software im Zusammenhang mit Microsoft Office Hoch Remotecodeausführung Supportartikel zu Updates für Microsoft Office: 4484130, 4484123, 4484112, 4462176, 4475558, 4475554, 4475569, 4475595
Software im Zusammenhang mit Microsoft SharePoint Hoch Remotecodeausführung Microsoft SharePoint Server 2019: 4484110
Microsoft SharePoint Enterprise Server 2016: 4484111
Microsoft SharePoint Enterprise Server 2013: 4462215
Microsoft SharePoint Foundation 2013: 4475608, 4484122
Microsoft SharePoint Foundation 2010: 4484131
SQL Server Management Studio Hoch Veröffentlichung von Informationen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://portal.msrc.microsoft.com/de-de/security-guidance.
Microsoft Dynamics 365 Hoch Spoofing Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://portal.msrc.microsoft.com/de-de/security-guidance.
Open Enclave SDK Hoch Veröffentlichung von Informationen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://portal.msrc.microsoft.com/de-de/security-guidance.
Azure App Service in Azure Stack Kritisch Rechteerweiterungen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://portal.msrc.microsoft.com/de-de/security-guidance.
Windows Update-Assistent Hoch Rechteerweiterungen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://portal.msrc.microsoft.com/de-de/security-guidance.
ChakraCore Kritisch Remotecodeausführung ChakraCore ist die zentrale Komponente von Chakra. Hierbei handelt es sich um das extrem leistungsfähige JavaScript-Modul, auf dem in HTML/CSS/JS geschriebene Microsoft Edge- und Windows-Anwendungen basieren. Weitere Informationen finden Sie unter https://github.com/Microsoft/ChakraCore/wiki. Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.

Beginnend mit April 2017 hat Microsoft die bisher verwendeten Sicherheitsbulletin-Webseiten durch den Leitfaden für Sicherheitsupdates ersetzt. Das neue Portal soll durch die vielfältigen Such- und Filterfunktionen einen besseren Überblick über neue Updates bieten.

Für jede Windows 10 Version veröffentlicht Microsoft ein eigenes kumulatives Update, welche die entsprechenden Windows 10 Versionen auf neue Build-Nummern hebt:

  • Windows 10 Version 1903 Build 18362.388
  • Windows 10 Version 1809 Build 17763.775
  • Windows 10 Version 1803 Build 17134.1040
  • Windows 10 Version 1709 Build 16299.1421
  • Windows 10 Version 1703 Build 15063.2079
  • Windows 10 Version 1607 Build 14393.3243
  • Windows 10 Version 1507 (RTM) Build 10240.18335

Infos zum Microsoft September-Patchday 2019

Microsoft Logo

Nachdem die letzten Microsoft-Patchdays mit verhältnismäßig wenig Updaten daher kamen, gibt es im September wieder deutlich mehr Sicherheitslücken zu stopfen. Neben kritischen Lücken in fast allen Microsoft-Betriebssystemen und dem Internet Explorer, sind auch SharePoint, Team Foundation Server, Azure DevOps Server und ChakraCore von solchen betroffen. Die Sicherheitslücken der anderen Produkte werden lediglich mit “hoch” eingestuft.

Produktfamilie Maximaler Schweregrad
Maximale Auswirkung Zugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1903, Version 1809, Version 1803, Version 1709 und Version 1703 Kritisch Remotecodeausführung Windows 10, Version 1903: 4515384; Windows 10, Version 1809: 4512578; Windows 10, Version 1803: 4516058; Windows 10, Version 1709: 4516066; Windows 10, Version 1703: 4516068;
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1903, Version 1803 und Version 1709) Kritisch Remotecodeausführung Windows Server, Version 1903: 4515384; Windows Server 2019: 4512578; Windows Server 2016: 4516044; Windows Server, Version 1803: 4516058
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008 Kritisch Remotecodeausführung Monatlicher Rollup für Windows 8.1, Windows Server 2012 R2 und Windows RT 8.1: 4516067; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4516064; monatlicher Rollup für Windows Server 2012: 4516055; reines Sicherheitsupdate für Windows Server 2012: 4516062; reines Sicherheitsupdate für Windows 7 und Windows Server 2008 R2: 4516033; monatlicher Rollup für Windows 7 und Windows Server 2008 R2: 4516065; monatlicher Rollup für Windows Server 2008: 4516026; reines Sicherheitsupdate für Windows Server 2008: 4516051
Internet Explorer Kritisch Remotecodeausführung Kumulatives Update für Internet Explorer: 4516046. Updates für Internet Explorer sind auch in Updatepaketen für die oben aufgelisteten Windows-Versionen enthalten.
Software im Zusammenhang mit Microsoft Office Hoch Veröffentlichung von Informationen Supportartikel zu Updates für Microsoft Office: 4475574, 4475566, 4475579, 4475607, 4475583, 4464566, 4461631, 4475589, 4464548, 4475611, 4475591, 4475599 und 4515509.
Software im Zusammenhang mit Microsoft SharePoint Kritisch Remotecodeausführung Microsoft SharePoint Server 2019: 4475596
Microsoft SharePoint Enterprise Server 2016: 4475590
Microsoft SharePoint Foundation 2010: 4475605
Microsoft Exchange Server Hoch DoS (Denial of Service) Supportartikel für Updates für Microsoft Exchange Server 2016 und 2019: 4515832
.NET Framework-related software Hoch Rechteerweiterungen Supportartikel im Zusammenhang mit Updates für .NET Framework: 4516044, 4516070, 4516068, 4514604, 4514599, 4514603, 4514598, 4516066, 4516058, 4514354, 4514355, 4514356, 4514357, 4514601 und 4514359.
.NET Core und ASP.NET Core Hoch Rechteerweiterungen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.
Visual Studio Hoch Rechteerweiterungen Supportartikel für Updates für Visual Studio: 4513696. Siehe auch: https://aka.ms/vs/16/release/latest
Team Foundation Server and Azure DevOps Server 2019 Kritisch Remotecodeausführung Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.
ChakraCore Kritisch Remotecodeausführung ChakraCore ist die zentrale Komponente von Chakra. Hierbei handelt es sich um das extrem leistungsfähige JavaScript-Modul, auf dem in HTML/CSS/JS geschriebene Microsoft Edge- und Windows-Anwendungen basieren. Weitere Informationen finden Sie unter https://github.com/Microsoft/ChakraCore/wiki. Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.
Adobe Flash Player Kritisch Remotecodeausführung Sicherheitsempfehlung für Adobe Flash Player: ADV190022
Supportartikel für Adobe Flash Player: 4516115
Rome SDK 1.4.1 Hoch Veröffentlichung von Informationen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.
Yammer für Android Hoch Umgehung von Sicherheitsfunktionen Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates.

Beginnend mit April 2017 hat Microsoft die bisher verwendeten Sicherheitsbulletin-Webseiten durch den Leitfaden für Sicherheitsupdates ersetzt. Das neue Portal soll durch die vielfältigen Such- und Filterfunktionen einen besseren Überblick über neue Updates bieten.

Für jede Windows 10 Version veröffentlicht Microsoft ein eigenes kumulatives Update, welche die entsprechenden Windows 10 Versionen auf neue Build-Nummern hebt:

  • Windows 10 Version 1903 Build 18362.356
  • Windows 10 Version 1809 Build 17763.737
  • Windows 10 Version 1803 Build 17134.1006
  • Windows 10 Version 1709 Build 16299.1387
  • Windows 10 Version 1703 Build 15063.2045
  • Windows 10 Version 1607 Build 14393.3204
  • Windows 10 Version 1507 (RTM) Build 10240.18333

“www” und “https://” in Chrome-Adresszeile anzeigen

Ab Chrome 83 funktioniert die Wiederherstellung der vollständigen URL so: https://www.antary.de/2020/06/07/www-und-https-in-chrome-adresszeile-ab-chrome-83/

Der vor einigen Wochen veröffentlichte Chrome 76 bringt unter anderem eine Änderung der Adresszeile mit sich.  Internet-Adressen werden nun standardmäßig ohne “https://” und “www” angezeigt.

Bereits im September 2018 hatte Google die Adresszeile des Chrome Browsers überarbeitet, sodass “www” und “triviale Subdomains” ausgeblendet wurden. Die Kritik der Nutzer war groß und Google ruderte nach kurzer Zeit wieder zurück. Allerdings hatten die Entwickler damals schon angekündigt, dass die Subdomain “www” eines Tages wieder ausgeblendet werden würde. Mit Chrome 76 wurde diese Ankündigung nun umgesetzt. Laut Google wurde einige Monate mit der URL-Darstellung experimentiert und man lege großen Wert auf Einfachheit und Nutzbarkeit. Die URL-Komponenten, die für viele Chrome-User irrelevant sind, wurden zur besseren Lesbarkeit weggelassen.

Es mag sein, dass viele Nutzer nicht genau wissen, was sich hinter den URL-Bestandteilen “https://”, “http://” sowie “www” verbirgt. Dennoch bin ich der Meinung, dass diese ein wichtiger Bestandteil der URL sind und deshalb nicht ausgeblendet werden sollten. Außerdem liefern sie für versierte Anwender Informationen über Inhalt und Struktur der Webseite. Viele Reaktionen im Chromium Bug-Tracker sehen das ähnlich.

Glücklicherweise lässt sich die Anzeige aller URL-Bestandteile wieder relativ einfach aktivieren.

Vollständige URL-Anzeige in Chrome aktivieren

  1. Öffnet einen neuen Tab in Chrome und gebt dort “chrome://flags/” ein.
  2. Oben in der Suche nach “Omnibox UI Hide” suchen.
  3. Die drei Werte von “Default” auf “Disabled” ändern.
  4. Anschließend unten auf den Button “Relaunch Now” klicken”.
  5. Nach einem Neustart von Chrome wird die komplette URL angezeigt.

Eine alternative Lösung ist die Installation der Erweiterung “Suspicious Site Reporter“. Das Add-on ist eigentlich dazu gedacht, verdächtige Webseiten an Google zu melden. An netter Nebeneffekt sorgt es allerdings für eine “unzensierte” Adressleiste.

Kategorien: Software & Apps

Custom ROM auf Xiaomi Smartphones installieren

Xiaomi Logo

Nach rund einem Jahr mit dem Xiaomi Redmi Note 5 stand bei mir ein Smartphone-Wechsel an. Da ich unbedingt ein kompakteres Smartphone haben wollte, bin ich schlussendlich beim Xiaomi Mi 9 SE gelandet. Zähneknirschend habe ich den relativ kleinen Akku (3.070 mAh) und die fehlende Benachrichtigungs-LED akzeptiert. Ein Smartphone, welches zu 100 Prozent alle gewünschten Features beinhaltet und gleichzeitig noch halbwegs erschwinglich ist, existiert sowieso nicht ;-)

In den letzten Wochen wurden die ersten Custom ROMs für das Xiaomi Mi 9 SE veröffentlicht und die gravierendsten Probleme behoben. Nachdem beim Remi Note 5 der Support für LineageOS eingestellt wurde, habe ich mich kurzerhand dazu entschlossen, anderen ROMs eine Chance zu geben. Für das Mi 9 SE existieren aktuell sowieso noch nicht viele Alternativen, weshalb ich mich für crDroid entschieden habe. crDroid basiert auf AOSP bzw. LineageOS , bringt aber zusätzliche Anpassungsmöglichkeiten aus einigen anderen ROMs mit.

Nachfolgend möchte ich kurz das Vorgehen beschreiben, wie ihr auf ein neues Smartphone von Xiaomi eine beliebige Custom ROM bekommt. Wie oben bereits erwähnt, beziehe ich mich dabei auf crDroid und das Mi 9 SE. Das Vorgehen sollte aber bis auf kleine Anpassungen für alle neuen Xiaomi-Smartphones und für viele andere Custom ROMs gültig sein.

Bootloader entsperren

Zunächst muss der Bootloader eures Xiaomi-Smartphones entsperrt werden. Denkt daran, dass dabei all eure Daten auf dem Smartphone gelöscht werden. Wer das Gerät also bereits genutzt hat, sollte vorher dem Entsperren des Bootloaders ein Backup anfertigen.

Hier die einzelnen Schritte zum Bootloader Entsperren in einer kurzen Übersicht:

  1. Voraussetzung ist ein funktionierendes “adb” und “fastboot”. Empfehlen kann ich den 15 seconds ADB Installer.
  2. Mi-Account erstellen und mit diesem auf dem Smartphone anmelden. Unter MIUI 10 funktioniert das folgendermaßen:
    1. Einstellungen -> Mein Gerät
    2. Mehrmals auf den Punkt “MIUI-Version” klicken, bis die Entwickleroptionen freigeschaltet werden.
    3. Dann zu “Einstellungen” -> “Kategorie System & Gerät -> Weitere Einstellungen” -> “Entwickleroptionen”.
    4. Unter “Mi Entsperr-Status”mit eurem Mi-Account einloggen.
  3. Ab diesem Zeitpunkt beginnt die Wartezeit, welche bis zu 360 Stunden (15 Tage) betragen kann. Bei mir waren es erfreulicherweise nur 7 Tage. Wie lange es bei euch dauert, seht ihr im nächsten Schritt.
  4. Mi Unlock Tool downloaden (neueste Version direkt von Xiaomi).
  5. Mi Unlock Tool starten. Anschließend mit eurem Mi-Account anmelden.
  6. Smartphone ausschalten, per USB mit eurem PC verbinden und in den Fastboot-Modus starten (volume down und Power-Taste gleichzeitig drücken).
  7. Versuchen das Smartphone zu entsperren. Jetzt sollte euch die Wartezeit angezeigt werden.
  8. Nach der Wartezeit erneut mit Schritt 5 beginnen. Solltet ihr einen Fehler bekommen, könnt ihr evtl. auch eine ältere Version des Mi Unlock Tools probieren. Bei mir hatte die neueste Version nicht funktioniert, Version 2.3.803.10 aber problemlos.

    Mi Unlock

Custom Recovery (TWRP) installieren

Sobald der Bootloader entsperrt ist, muss im zweiten Schritt das Custom Recovery TWRP (Team Win Recovery Project) installiert werden. Die aktuelle TWRP-Version für euer Gerät findet ihr entweder direkt auf der TWRP-Homepage oder im xda-Forum.

  1. Smartphone im Fastboot-Modus starten (volume down und Power-Taste gleichzeitig drücken) und via USB mit eurem PC verbinden.
  2. Prüfen ob das Gerät korrekt erkannt wird:
    fastboot devices
  3. TWRP-Recovery flashen. Der erste Befehl ist nur notwendig, wenn euer TWRP in einem separaten Ordner liegt.
    cd C:\Users\USERNAME\Desktop
    fastboot flash recovery twrp-3.3.1-7a-Mi9SE.img

    Auf keinen Fall “fastboot boot …” nutzen, da ansonsten die Verschlüsselung beschädigt wird und ihr zur Reparatur “data” neu formatieren müsstet.
  4. TWRP-Recovery booten (volume up und Power-Taste gleichzeitig drücken) und warten bis TWRP geladen ist.
  5. Modifizierung des Dateisystems erlauben.

Custom ROM installieren

Zwei Drittel sind schon geschafft, jetzt folgt das Flashen der Custom ROM (in meinem Fall crDroid) und Co. Zunächst müsst ihr ein paar Downloads tätigen und die Dateien auf das Smartphone legen. Das Kopieren auf das Smartphone sollte auch direkt unter TWRP funktionieren.

Jetzt könnt ihr loslegen.
  1. In TWRP Recovery booten (volume up und Power-Taste gleichzeitig drücken).
  2. Im Recovery den Punkt “Wipe“ aufrufen, dann den Button “Format Data” klicken. Anschließend “Swipe to Factory Reset ausführen” und erneut in TWRP Recovery booten.
  3. Neue Firmware installieren, dabei müsst ihr auf eine kompatible Version achten, Stichwort Anti-Rollback. Wenn das Custom ROM keine vendor.img enthält, müsst ihr diese zusätzlich installieren.
  4. Custom ROM (crDroid) installieren.
  5. Open GApps installieren.
  6. Smartphone neustarten (Reboot –> System).*
  7. ROM einrichten.
  8. Erneut in TWRP Recovery booten.
  9. Root (Magisk) und ggf. Kernel installieren.
  10. Smartphone neustarten (Reboot –> System).
  11. (optional) Magisk Manager einrichten.

*Bei einem Boot-Loop muss eine weitere Datei (vbmeta.img) via Fastboot geflasht werden, um den Loop zu beheben.

fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img

Infos zum Microsoft August-Patchday 2019

Microsoft Logo

Auch im August fällt der Microsoft-Patchday relativ “klein” aus. Neben kritischen Sicherheitslücken in fast allen Microsoft-Betriebssystemen wird auch eine kritische Lücke im Internet Explorer gefixt. Microsofts Edge ist von keiner Lücke betroffen.

Produktfamilie Maximaler Schweregrad
Maximale Auswirkung Zugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1903, Version 1809, Version 1803, Version 1709 und Version 1703 Kritisch Remotecodeausführung Windows 10, Version 1903: 4512508; Windows 10, Version 1809: 4511553; Windows 10, Version 1803: 4512501; Windows 10, Version 1709: 4512516; Windows 10, Version 1703: 4512507
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1803 und Version 1709) Kritisch Remotecodeausführung Windows Server, Version 1903: 4512508; Windows Server 2019: 4511553; Windows Server 2016: 4512517; Windows Server, Version 1803: 4512501
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008 Kritisch Remotecodeausführung Monatlicher Rollup für Windows 8.1, Windows Server 2012 R2 und Windows RT 8.1: 4512488; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4512489; reines Sicherheitsupdate für Windows Server 2012: 4512482; monatlicher Rollup für Windows Server 2012: 4512518; reines Sicherheitsupdate für Windows 7, Windows Server 2008 R2 und Windows Server 2008: 4512486; monatlicher Rollup für Windows 7 und Windows Server 2008 R2: 4512506; monatlicher Rollup für Windows Server 2008: 4512476; reines Sicherheitsupdate für Windows Server 2008: 4512491
Internet Explorer Kritisch Remotecodeausführung Kumulatives Update für Internet Explorer: 4511872. Updates für Internet Explorer sind auch in Updatepaketen für die oben aufgelisteten Windows-Versionen enthalten.
Software im Zusammenhang mit Microsoft Office Kritisch Remotecodeausführung Die Anzahl der KB-Artikel bezüglich Software im Zusammenhang mit Microsoft Office für jede monatliche Sicherheitsupdateveröffentlichung hängt von der Anzahl der CVEs und der Anzahl der betroffenen Komponenten ab. Es sind insgesamt zu viele KB-Artikel, die nicht alle in dieser Übersicht aufgelistet werden können. Ausführliche Informationen zu diesen Artikeln finden Sie im Leitfaden für Sicherheitsupdates.
Software im Zusammenhang mit Microsoft SharePoint Kritisch Remotecodeausführung Microsoft SharePoint Server 2019: 4475555
Microsoft SharePoint Server 2010: 4475530
Microsoft SharePoint Enterprise Server 2016: 4475549
Microsoft SharePoint Enterprise Server 2013: 4462137, 4475557
Microsoft SharePoint Foundation 2013: 4475565
Microsoft SharePoint Foundation 2010: 4475575
Microsoft Antimalware-Software Hoch Rechteerweiterungen Weitere Informationen zu den Updates für Microsoft Antimalware-Software finden Sie unter https://www.microsoft.com/wdsi.
Microsoft Visual Studio Hoch Rechteerweiterungen https://aka.ms/vs/16/release/latest
Microsoft Dynamics 365 Hoch Rechteerweiterungen Microsoft Dynamics 365 (on-premises), Version 9.0: 4508724
ChakraCore Kritisch Remotecodeausführung ChakraCore ist die zentrale Komponente von Chakra. Hierbei handelt es sich um das extrem leistungsfähige JavaScript-Modul, auf dem in HTML/CSS/JS geschriebene Microsoft Edge- und Windows-Anwendungen basieren. Weitere Informationen finden Sie unter https://github.com/Microsoft/ChakraCore/wiki. Weitere Informationen finden Sie im Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdates

Beginnend mit April 2017 hat Microsoft die bisher verwendeten Sicherheitsbulletin-Webseiten durch den Leitfaden für Sicherheitsupdates ersetzt. Das neue Portal soll durch die vielfältigen Such- und Filterfunktionen einen besseren Überblick über neue Updates bieten.

Für jede Windows 10 Version veröffentlicht Microsoft ein eigenes kumulatives Update, welche die entsprechenden Windows 10 Versionen auf neue Build-Nummern hebt:

  • Windows 10 Version 1903 Build 18362.329
  • Windows 10 Version 1809 Build 17763.720
  • Windows 10 Version 1803 Build 17134.984
  • Windows 10 Version 1709 Build 16299.1365
  • Windows 10 Version 1703 Build 15063.2021
  • Windows 10 Version 1607 Build 14393.3181
  • Windows 10 Version 1507 (RTM) Build 10240.18308