Antary

3 Millionen Let’s-Encrypt-Zertifikate fehlerhaft

Let' s Encrypt Logo

Ende Februar hat die Zertifizierungsstelle (CA) Let’s Encrypt die Ausstellung von über einer Milliarde Zertifikaten bekannt gegeben. Wenige Tage später wurde ein Fehler bei der Zertifikatsausstellung publik, der rund drei Millionen Zertifikate betrifft. Anfänglich sah es so aus, als ob Let’s Encrypt alle drei Millionen Zertifikate zurückzieht. Nach wenigen Tagen ist aber klar, dass 1,7 Millionen Zertifikate zurückgezogen wurden und 1,3 Millionen gültig bleiben.

Der Fehler betrifft die Prüfung von CAA-DNS-Records, welche nicht korrekt durchgeführt wurde. Mittels eines CAA-Records ist es Domaininhabern möglich festzulegen, welche Zertifizierungsstellen berechtigt sind, Zertifikate auszustellen. Bei der Domainvalidierung prüft Let’s Encrypt neben dem Domaininhaber auch den CAA-Record. Die Domainvalidierung ist bei Let’s Encrypt für 30 Tage gültig. Hier genau liegt das Problem: Laut den Regeln des CA/Browser-Forums darf die Prüfung des CAA-Records nur maximal acht Stunden vor der Zertifikatsausstellung stattfinden. An diese Regeln müssen sich alle Zertifizierungsstellen halten.

Nach der Entdeckung des Fehlers hat Let’s Encrypt die Zertifikatsausstellung für einige Stunden eingestellt, bis der Fehler behoben wurde. Anschließend wurden viele betroffene Nutzer per Mail informiert. Da die Angabe einer E-Mail-Adresse nur optional ist, konnten jedoch nicht alle Nutzer informiert werden. Wer betroffen ist, sollte sich schnellstmöglich ein neues Zertifikat ausstellen lassen. Auf dieser Webseite könnt ihr prüfen, ob ihr davon betroffen seid oder nicht.

Weitere Regeln des CA/Browser-Forums besagen, dass alle fehlerhaften Zertifikate innerhalb von fünf Tagen zurückgezogen werden müssen. Let’s Encrypt hat sich allerdings bewusst dagegen entschieden und nur 1,7 Millionen alte Zertifikate zurückgezogen, die bereits durch neuere getauscht wurden. Bei 445 Zertifikaten wurde in der Zwischenzeit ein CAA-Record gesetzt, welche eine Zertifikatsausstellung durch Let’s Encrypt untersagt. Diese Zertifikate wurden ebenfalls alle zurückgenommen. Die noch im Einsatz befindlichen 1,3 Millionen Zertifikate bleiben weiterhin gültig. Das Zurückziehen aller Zertifikate hätte laut einem Let’s-Encrypt-Mitarbeiter zu viel Schaden geführt, weshalb man sich dagegen entschieden hat. Darüber hinaus ist das Risiko relativ gering, da bei den fehlerhaften Zertifikaten lediglich der Check des CAA-Records nicht zum richtigen Zeitpunkt durchgeführt wurde.

Kategorien: Internet

Wo die Deutschen suchen nach Rabatte?

In diesem Artikel stellen wir Ihnen Geschäfte vor, in denen Kunden aus Deutschland am häufigsten nach Rabatten suchen. Wir haben die letzten Tendenzen in vier beliebtesten Shops analysiert und die Vergleichscharakteristik nach Regionen zusammengestellt.

Wenn Sie einen Gutschein für ein Geschäft suchen, können Sie eines der erwähnten Geschäfte auswählen. Sie alle verfügen über günstige Angebote. Und wenn Sie sich über andere Gutscheine informieren möchten, blättern Sie Prospekte Online auf der Webseite Rabato.

1. About You

About You bietet nicht nur ausgezeichnete Qualität der Kleidung, sondern auch ziemlich günstige Preise. Seit 2013 bietet dieses Online-Geschäft viele bekannte Marken an.

Wenn Sie die Kleidung von Tom Tailor oder Adidas mögen, ist dieses Geschäft das Richtige für Sie. Dort finden Sie Waren für Frauen, Männer und Kinder. Besonders attraktiv ist es, wenn Sie in About You einen Gutschein erhalten. Um Wäsche, Kleidung, Schuhe sowie Accessoires günstig zu kaufen, suchen viele Deutschen nach attraktiven Gutscheinen.

Laut unserer Untersuchung suchen die Bewohner von Nordrhein-Westfalen und Thüringen die Rabatte für dieses Geschäft am häufigsten.

2. OTTO

Ein anderes bekannte Geschäft, wo viele günstige Rabatte angeboten werden, ist OTTO. Dieses Geschäft gehört zu den berühmtesten Online-Versendern der Welt und bietet über 2 Millionen Waren. In diesem Geschäft kann man Produkte für die ganze Familie zu sehr attraktiven Preisen kaufen. Diejenigen, die noch mehr sparen möchten, können sich einen OTTO Gutschein sichern.

OTTO sorgt seit 1949 dafür, dass dort die ganze Familie hochqualitative Produkte für jeden Geschmack finden kann. Es ist anzumerken, dass über 90 Prozent der Kunden dieses Geschäfts Gutscheincodes benutzen, um ein gutes Rabatt zu erhalten. Es gibt zahlreiche Rabattcoupons und vielfältige Sparaktionen für jeden Geschmack.

Es ist kein Wunder, dass so viele Deutschen günstige Angebote für OTTO suchen. Besonders beliebt sind sie in Sachsen-Anhalt und Brandenburg.

3. IKEA

Möchten Sie Ihr Haus mit qualitativen und günstigen Möbeln ausrichten? Dann ist IKEA das perfekte Geschäft für Ihre Bedürfnisse. In IKEA wird eine umfangreiche Auswahl an Sofas, Betten, Möbel für Küche, Kleiderschränke, Kindermöbel usw. zu attraktiven Preisen verkauft. Und eine der besten Funktionen dieses Geschäfts besteht darin, dass es häufig tolle Gutscheine anbietet, die den Kunden die Möglichkeit gewähren, Möbeln günstig zu kaufen.

IKEA ist die größte Möbelhauskette der Welt, die unzählige Niederlassungen in vielen Ländern, einschließlich Deutschland betreibt. Es besteht keine Notwendigkeit, ins Geschäft zu gehen, da IKEA auch als Online-Shop funktioniert, in dem komfortable Bestellung der Möbel möglich ist.

In Deutschland sind Gutscheine für dieses Geschäft sehr beliebt. In Hamburg, Nordrhein-Westfalen und Berlin erhielt es die größte Popularität.

4. home24

Im Online-Shop für Möbel home24 können Sie mehr als 100.000 verschiedene Artikel für Ihr Haus ansehen. Egal ob Sie Möbel oder Wohnaccessoires suchen, da in diesem Geschäft Sie alles finden, was Sie für Ihr Haus brauchen. Und wenn Sie das Angebot von home24 mit einem Gutschein kombinieren, können Sie Ihr Geld erheblich sparen.

Heute sollten Sie nicht mehr ein Möbelgeschäft besuchen, um Ihr Haus neu einzurichten. Als eine gute Alternative bietet home24 Ihnen die Funktion eines Online-Shops an, wo Sie dieselbe große Auswahl an Möbeln sehen können. Wenn Sie zum Beispiel ein neues Sofa, Bett, einen Tisch oder Kleiderschrank kaufen, werden alle diesen Waren zu Ihnen nach Hause geliefert. Bei home24 können Sie sich inspirieren lassen, was die neuesten Trends betrifft. In der Rubrik für Schlafzimmer, Wohnzimmer sowie Esszimmer finden Sie viele ausgezeichnete Wohnaccessoires.

Das Geschäft home24 ist in Deutschland sehr beliebt. Große Auswahl an hochqualitativen Waren, günstige Preise und die Möglichkeit, alles online zu bestellen, machen das Einkaufen sehr bequem. Außerdem suchen viele Deutschen nach Rabatten für dieses Geschäft. Unsere Untersuchung hat gezeigt, dass in Brandenburg und Nordrhein-Westfallen die Gutscheine für dieses Geschäft besonders populär sind.

Fazit

Wir haben die Suchanfrage von Rabatten für die beliebtesten Geschäfte in Deutschland analysiert. Aus unserer Untersuchung folgt, dass die Bewohner von Nordrhein-Westfallen die Gutscheine für die Shops am häufigsten benutzen. Nur das Geschäft OTTO ist eine Ausnahme.

Kategorien: Internet

WireGuard – neues VPN-Protokoll mit großer Zukunft

WireGuard Logo

WireGuard erfreut sich seit geraumer Zeit wachsender Beliebtheit. Hinter WireGuard verbirgt sich sowohl ein VPN-Protokoll, als auch eine VPN-Software. Während es vor zwei Jahren quasi unbekannt war, hat die Bekanntheit in den letzten Monaten stark zugenommen. Grund dafür ist neben der guten Performance und dem schnellen Verbindungsaufbau sicherlich auch die Aufnahme in den stabilen Linux Kernel 5.6, welcher Anfang April 2020 erscheinen dürfte.

Ich selbst bin im Herbst 2019 auf WireGuard gestoßen, als jemand in einem Forum WireGuard vorstellte und als „heißen Scheiß“ bezeichnet hatte. Mittlerweile nutze ich WireGuard seit mehreren Monaten und kann dieser Aussage nur zustimmen :-)

Einleitung

Das VPN-Protokoll WireGuard und die gleichnamige Open Source Software wurden von Jason A. Donenfeld ins Leben gerufen. WireGuard sieht sich selber als extrem einfache, aber dennoch schnelle und moderne VPN-Lösung. Gleichzeitig soll es durch die Nutzung der neuesten Kryptographie-Techniken extrem sicher sein. Im direkten Vergleich mit IPsec und OpenVPN soll es leistungsfähiger, einfacher, schlanker und schneller sein.

Ursprünglich wurde WireGuard nur für den Linux-Kernel entwickelt, ist mittlerweile aber zudem für Windows, macOS, BSD, iOS und Android verfügbar.

Die ersten Snapshots wurden im Juni 2016 veröffentlich. Zwei Jahre später im Juni 2018 wurde der Code und das Protokoll als experimentell bezeichnet und darauf hingewiesen, dass noch kein stabiles Release existiert. Dies trifft bis zum heutigen Tag zu, könnte sich aber bald ändern.

Rund eineinhalb Jahre nach dem Vorschlag von Donenfeld zur Aufnahme in den Hauptzweig ist es nun soweit. Linus Torvalds hat vor wenigen Tagen den Entwicklungszweig Net-Next in den Hauptzweig der Kernel-Entwicklung integriert. Damit wird WireGuard erstmals Teil eines stabilen Linux-Kernels. Der Kernel 5.6 wird für Anfang April erwartet. Grund der langen Verzögerung war der Crypto-Unterbau von WireGuard, welcher einen anderen Ansatz als die Crypto-API des Linux-Kernels verfolgt und deshalb für Unstimmigkeiten gesorgt hatte. Letztlich wurden die neuen Crypto-Funktionen aber im kürzlich veröffentlichten Kernel 5.5 umgesetzt.

Technik

Der Grundgedanke hinter WireGuard ist erfrischend neu und simpel. WireGuard arbeitet ausschließlich auf Schicht 3 des OSI-Modells und ermöglicht die Netzwerkkopplung auf Peer-to-Peer-Basis. Softwareseitig gibt es keine Unterschiede zwischen den Teilnehmern. Alleine die Konfiguration entscheidet, ob ein Peer als Client oder Server arbeitet. Aus diesem Grund sind sogenannte Road-Warrior-Szenarien mit einem zentralen Server und mehreren Clients kein Problem.

Unterstützt wird neben IPv4 auch IPv6. Des Weiteren kann IPv4 in IPv6 getunnelt werden und umgekehrt. Die Verbindung zwischen zwei Peers wird über einen einzelnen, frei wählbaren UDP-Port geregelt. Standardmäßig ist dies UDP-Port 51820.

Zum Verbindungsaufbau wird auf beiden Seiten der VPN-Verbindung lediglich ein Schlüsselpaar benötigt. Der private Schlüssel bleibt dabei lokal, der öffentliche Schlüssel wird der Gegenstelle bekannt gemacht. Auf eine Zertifikat-Infrastruktur kann getrost verzichtet werden. Außerdem kann optional ein symmetrischer Schlüssel (PSK) verwendet werden, der die Verbindung zusätzlich sichert.

Andere VPN-Protokolle unterstützen eine Vielzahl von Algorithmen zum Schlüsselaustausch, zum Chiffrieren und zur Hash-Berechnung. WireGuard geht einen anderen Weg und kennt für jede Aufgabe nur einen fest codierten Algorithmus. Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung, Poly1305 für die Authentifizierung, BLAKE2 für das Hashing und SipHash24 für die Hashtable.

Durch die vollständige Neuentwicklung und den Fokus auf Grundfunktionen kann komplett auf Altlasten verzichtet werden, was sich auch im Quelltext zeigt. Während OpenVPN und IPSec auf mehrere Hunderttausend Zeilen Code kommen, begnügt sich WireGuard mit ca. 7.000 Zeilen.

Ein weiteres Merkmal ist das eingebaute „Roaming“. Wechselt ein Peer (Client), also z.B. ein Smartphone, zwischen WLAN und Mobilfunknetz, bleibt die WireGuard-Verbindung bestehen und der Anwender bekommt davon nichts mit. Selbst wenn es in seltenen Fällen zu einem Verbindungsabbruch führt, ist die Verbindung fast unmittelbar wiederhergestellt. Andere VPN-Protokolle wie IPSec oder OpenVPN sind im direkten Vergleich quälend langsam.

Die gute Performance ist unter anderem darin begründet, dass WireGuard unter Linux direkt im Kernel arbeitet. Somit entfallen häufige Kontextwechsel zwischen Userland und Kernel und die Datenpakete können deutlich schneller abgearbeitet werden. Zudem besitzt WireGuard spezielle Optimierungen für die MIPS-Prozessor-Architektur, sodass es auch für leistungsschwache Geräte interessant ist.

Fazit

Ich habe WireGuard vor ca. fünf Monaten auf meinem Raspberry Pi und meinem Smartphone installiert. Seitdem ist mein Smartphone zu 100% über den WireGuard-VPN-Tunnel online. Weder daheim noch unterwegs musste ich bisher irgendwelche Probleme feststellen. Die Performance ist super und das Roaming-Verhalten spitze. Wie vom Entwickler versprochen gibt es hier keine Abbrüche oder Verzögerungen. Einziger Negativpunkt ist das spärliche Logging auf beiden Seiten.

In einem weiteren Artikel werde ich detailliert auf die Einrichtung unter Raspbian Buster und Android eingehen. Stay tuned!

Infos zum Microsoft Februar-Patchday 2020

Microsoft Logo

Der Microsoft-Patchday im Februar kommt erstmals ohne Patches für Windows 7 und Server 2008 bzw. 2008 R2 daher. Kritische Sicherheitslücken werden für alle Betriebssysteme, Internet Explorer und ChakraCore behoben. Für den Rest wird die Schwere der Sicherheitslücken lediglich als „hoch“ eingestuft.

ProduktfamilieMaximaler Schweregrad
Maximale AuswirkungZugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1909, Version 1903, Version 1809, Version 1803, Version 1709KritischRemotecodeausführungWindows 10, Version 1903, und Windows 10, Version 1909: 4532693; Windows 10, Version 1809: 4532691; Windows 10, Version 1803: 4537762; Windows 10, Version 1709: 4537789; Alle: 4524244
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1909, Version 1903 und Version 1803)KritischRemotecodeausführungWindows Server 2019: 4532691; Windows Server 2016: 4537764; Windows Server, Version 1903, und Windows Server, Version 1909: 4532693; Windows Server, Version 1803: 4537762; Alle: 4524244
Windows 8.1, Windows Server 2012 R2 und Windows Server 2012KritischRemotecodeausführungMonatlicher Rollup für Windows 8.1 und Windows Server 2012 R2: 4537821; Windows Server 2012, Windows 8.1 und Windows Server 2012 R2: 4502496; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4537803; monatlicher Rollup für Windows Server 2012: 4537814; reines Sicherheitsupdate für Windows Server 2012: 4537794;
Internet ExplorerKritischRemotecodeausführungKumulatives Update für Internet Explorer: 4537767
Software im Zusammenhang mit Microsoft OfficeHochRemotecodeausführungKB-Artikel im Zusammenhang mit Microsoft Office: 4484250, 4484156, 4484163, 4484265, 4484256, 4484254, 4484267
Software im Zusammenhang mit Microsoft SharePointHochSpoofingKB-Artikel im Zusammenhang mit Microsoft SharePoint: 4484259, 4484264, 4484255
Microsoft Exchange ServerHochRemotecodeausführungKB-Artikel im Zusammenhang mit Microsoft Exchange Server: 4536988, 4536987, 4536989
Microsoft SQL ServerHochRemotecodeausführungKB-Artikel im Zusammenhang mit Microsoft SQL Server: 4535706, 4532098, 4532095, 4535288, 4532097
ChakraCoreKritischRemotecodeausführungChakraCore 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 und https://github.com/Microsoft/ChakraCore/releases/.
Adobe Flash PlayerHochRechteerweiterungenKB-Artikel im Zusammenhang mit Adobe Flash Player: 4537759. Sicherheitsempfehlung zu Adobe Flash Player: ADV200003
Microsoft Surface HubHochUmgehung von SicherheitsfunktionenKB-Artikel im Zusammenhang mit dem Sicherheitsupdate für Microsoft Surface Hub: 4537765. Weitere Informationen zum Update für diese Sicherheitsanfälligkeit finden Sie unter CVE-2020-0702.
Windows-Tool zum Entfernen bösartiger SoftwareHochRechteerweiterungenKB-Artikel im Zusammenhang mit dem Windows-Tool zum Entfernen bösartiger Software: 891716. Weitere Informationen zum Update für diese Sicherheitsanfälligkeit finden Sie unter CVE-2020-0733.

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.657
  • Windows 10 Version 1903 Build 18362.657
  • Windows 10 Version 1809 Build 17763.1039
  • Windows 10 Version 1803 Build 17134.1304
  • Windows 10 Version 1709 Build 16299.1686
  • Windows 10 Version 1607 Build 14393.3504
  • Windows 10 Version 1507 (RTM) Build 10240.18486

Xiaomi eröffnet ersten Mi Store in Deutschland

Xiaomi Logo

Der chinesische Hersteller Xiaomi hat innerhalb der letzten Jahre in Europa Fuß gefasst. Auch in Deutschland erlangt Xiaomi immer größere Beliebtheit. Ich setze beispielsweise seit geraumer Zeit nur noch auf Smartphones von Xiaomi, allerdings nicht mit dem hauseigenen Betriebssystem MIUI sondern mit Custom ROM.

Offensichtlich nimmt die Expansion nach Deutschland dieses Jahr mehr Fahrt auf. Xiaomi hat bekannt gegeben, dass im 2. Quartal dieses Jahr der erste Mi Store in Deutschland eröffnet werden soll. In einem Tweet wurde auch der Standort bekannt gegeben: Es ist Düsseldorf.

Weitere Details wie der genaue Eröffnungstermin und das geplante Sortiment wurden bislang allerdings nicht verraten. Bei LinkedIn sind aktuell zwei Stellen in Vollzeit ausgeschrieben, zum einen die Position als Sales Manager bei der Xiaomi Technology sowie einen Office Administrator.

Darüber hinaus startet Xiaomi ebenfalls im Q2 2020 mit dem Direktvertrieb via https://mi.com/de. Diese Neuigkeit ist zwar weniger interessant, da Produkte von Xiaomi bereits auf Amazon und diversen anderen deutschen Webseiten zu erwerben sind, aber dennoch erwähnenswert.

Kategorien: Hardware Smartphones

SSH-Keys direkt unter Windows 10 erstellen

Windows 10 OpenSSH-Client

Die Implementierung von OpenSSH in Windows 10 schreitet weiter voran. Mit Version 1709 hat Windows 10 erstmals einen SSH-Client und -Server erhalten. Ab Windows 10 1809 ist der OpenSSH-Client bereits standardmäßig installiert. Davor musste das optionale Feature von Hand aktiviert werden.

Darüber hinaus können SSH-Keys erzeugt werden, sofern der OpenSSH-Client installiert ist. Das Ganze funktioniert relativ einfach direkt aus der Eingabeeinforderung oder der PowerShell.

  1. „ssh-keygen“ eintippen und Enter-Taste drücken.
    ssh-keygen
  2. Anschließend wird ein Pfad und Dateiname für den Key vorgeschlagen. Wenn dieser passt könnt ihr mit der Eingabetaste zum nächsten Schritt, alternativ könnt ihr aber auch einen anderen Pfad und Namen vergeben.
  3. Jetzt könnt ihr eine Passphrase vergeben. Obwohl dieser Schritt optional ist, empfehle ich starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.
  4. Zum Schluss wird der Key-Fingerprint angezeigt. Der Public Key wird standardmäßig unter dem Namen „id_rsa.pub“ angelegt.

Hier alle Schritte im Überblick:

Windows 10 ssh-keygen

Selbstverständlich werden auch weitere Public Key Algorithmen und viele weitere Optionen unterstützt. Hier ein kleiner Überblick aller Möglichkeiten:

usage: ssh-keygen [-q] [-b bits] [-t dsa | ecdsa | ed25519 | rsa]
                  [-N new_passphrase] [-C comment] [-f output_keyfile]
       ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
       ssh-keygen -i [-m key_format] [-f input_keyfile]
       ssh-keygen -e [-m key_format] [-f input_keyfile]
       ssh-keygen -y [-f input_keyfile]
       ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]
       ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]
       ssh-keygen -B [-f input_keyfile]
       ssh-keygen -F hostname [-f known_hosts_file] [-l]
       ssh-keygen -H [-f known_hosts_file]
       ssh-keygen -R hostname [-f known_hosts_file]
       ssh-keygen -r hostname [-f input_keyfile] [-g]
       ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]
       ssh-keygen -T output_file -f input_file [-v] [-a rounds] [-J num_lines]
                  [-j start_line] [-K checkpt] [-W generator]
       ssh-keygen -s ca_key -I certificate_identity [-h] [-U]
                  [-D pkcs11_provider] [-n principals] [-O option]
                  [-V validity_interval] [-z serial_number] file ...
       ssh-keygen -L [-f input_keyfile]
       ssh-keygen -A
       ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]
                  file ...
       ssh-keygen -Q -f krl_file file ...

Wem die standardmäßigen 2048-Bit-RSA-Keys zu schwach sind, der kann mit folgenden Befehlen stärkere Keys erzeugen:

ssh-keygen -t rsa -b 4096
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Infos zum Microsoft Januar-Patchday 2020

Der erste Microsoft-Patchday im neuen Jahr 2020 ist gleichzeitig der letzte Patchday für Windows 7. Im Vergleich zu anderen Patchdays fällt der Januar relativ klein aus. Nichtsdestotrotz werden einige kritische Sicherheitslücken behoben. Neben fast allen Microsoft-Betriebssystemen bekommen auch der Internet Explorer, das .NET Framework, Microsoft Office, Microsoft Dynamics 365 Field Service und OneDrive für Android entsprechende Sicherheitsupdates.

ProduktfamilieMaximaler Schweregrad
Maximale AuswirkungZugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1909, Version 1903, Version 1809, Version 1803, Version 1709KritischRemotecodeausführungWindows 10, Version 1903, und Windows 10, Version 1909: 4528760; Windows 10, Version 1809: 4534273; Windows 10, Version 1803: 4534293; Windows 10, Version 1709: 4534276
Windows Server 2019, Windows Server 2016 und Server Core-Installationen (2019, 2016, Version 1909, Version 1903 und Version 1803)KritischRemotecodeausführungWindows Server, Version 1903, und Windows Server, Version 1909: 4528760; Windows Server 2019: 4534273; Windows Server 2016: 4534271; Windows Server, Version 1803: 4534293
Windows 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2 und Windows Server 2008KritischRemotecodeausführungMonatlicher Rollup für Windows 8.1, Windows Server 2012 R2 und Windows RT 8.1: 4534297; reines Sicherheitsupdate für Windows 8.1 und Windows Server 2012 R2: 4534309; monatlicher Rollup für Windows Server 2012: 4534283; reines Sicherheitsupdate für Windows Server 2012: 4534288; monatlicher Rollup für Windows 7 und Windows Server 2008 R2: 4534310; reines Sicherheitsupdate für Windows 7 und Windows Server 2008 R2: 4534314; monatlicher Rollup für Windows Server 2008: 4534303; reines Sicherheitsupdate für Windows Server 2008: 4534312
Internet ExplorerKritischRemotecodeausführungKumulatives Update für Internet Explorer: 4534251
Software im Zusammenhang mit Microsoft OfficeHochRemotecodeausführungKB-Artikel im Zusammenhang mit Office: 4484217, 4484243, 4484234, 4484223, 4484221, 4484236, 4484227
Software im Zusammenhang mit .NET FrameworkKritischRemotecodeausführungKB-Artikel im Zusammenhang mit .NET Framework: 4535102, 4534976, 4535104, 4534978, 4535103, 4534977, 4532936, 4532935, 4532933, 4535101, 4532938, 4535105, 4534979, 4534271, 4534306, 4534293
Microsoft Dynamics 365 Field Service (on-premise)HochSpoofingWeitere Informationen zu den Microsoft Dynamics Field Service-Updates finden Sie unter https://docs.microsoft.com/de-de/dynamics365/field-service/user-guide.
Microsoft OneDrive für AndroidHochUmgehung von SicherheitsfunktionenWeitere Informationen zu den Microsoft OneDrive für Android-Updates finden Sie unter https://portal.msrc.microsoft.com/de-de/security-guidance

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.592
  • Windows 10 Version 1903 Build 18362.592
  • Windows 10 Version 1809 Build 17763.973
  • Windows 10 Version 1803 Build 17134.1246
  • Windows 10 Version 1709 Build 16299.1625
  • Windows 10 Version 1607 Build 14393.3443
  • Windows 10 Version 1507 (RTM) Build 10240.18453

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 kurzer 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, 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.

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.

ProduktfamilieMaximaler Schweregrad
Maximale AuswirkungZugehörige KB-Artikel und/oder Supportwebseiten
Windows 10, Version 1909, Version 1903, Version 1809, Version 1803, Version 1709KritischRemotecodeausführungWindows 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)KritischRemotecodeausführungWindows 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 2008KritischRemotecodeausführungMonatlicher 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 ExplorerHochRemotecodeausführungKumulatives Update für Internet Explorer: 4530677;
Software im Zusammenhang mit Microsoft OfficeHochRemotecodeausführungKB-Artikel im Zusammenhang mit Office: 4484180, 4484193, 4484186, 4484169, 4475598, 4475601, 4484094, 4461590, 4484166, 4461613, 4484179, 4484182, 4484196, 4484190, 4484192, 4484184
Visual StudioKritischRemotecodeausführungWeitere Informationen siehe den Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdateguide
Software im Zusammenhang mit SQL ServerHochSpoofingWeitere Informationen siehe den Leitfaden für Sicherheitsupdates: https://aka.ms/securityupdateguide
Microsoft Authentication Library (MSAL) für AndroidHochVeröffentlichung von Informationenhttps://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 0.0.0.0
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktiviert lassen. 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 „without-password“ in Ordnung. Diese ist standardmäßig gesetzt und erlaubt eine Public-Key-Authentifizierung mit dem root Account.

#PermitRootLogin without-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.1.0/ssh-audit-2.1.0.tar.gz
tar -xvzf ssh-audit-2.1.0.tar.gz
~/ssh-audit-2.1.0/ssh-audit.py localhost

Alternativ könnt ihr auch Nmap dazu verwenden:

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

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.

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:

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:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
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