Mozilla… What the fuck is wrong with you?

In den letzten Tagen habe ich mich immer und immer wieder mit meinen Browsern beschäftigt. Ich versuche meine Daten möglichst nicht bei Firmen oder anderen zentralen Stellen abzuladen. Bisher hatte ich Mozilla eigentlich als eine recht neutrale Instanz im Hinterkopf, was Datenschutz angeht. Eine Instanz welche der „Underdog“ im Kampf gegen die Webkit/Blink übermacht ist. Nachdem Selbst Microsoft mittlerweile von Trinity (Internet Explorer) auf Webkit bzw. Blink gewechselt ist, wird es recht dünn auf dem Markt für Browserengines. Eigentlich gibt es nur noch zwei nennenswerte Engines. Webkit/Blink und Gecko.

Nur kurz zur Klärung:

„Blink“ ist ein Fork von Webkit. Blink und Webkit haben dieselbe Codebase, auch wenn Blink unabhängig vom Webkit Projekt entwickelt wird, teilen sich beide die Codebase und Funktionieren in etwa gleich. Der Unterschied zwischen Blink und Webkit sind einige Features wie z.B. das Auslagern von Teilen des Codes in eine Sandbox oder das parallele Benutzen von mehrerer Kerne. Da beide Engines, was das Darstellen von Webseiten angeht gleich funktionieren, betrachtet man im Ganzen Blink und Webkit als dieselbe Engine in verschiedenen Ausführungen. Man könnte es in etwa wie Chrome und Chromium sehen.

Webkit ist ursprünglich vom KDE Team entwickelt worden bis Apple irgendwann gedacht hatte: „Hey, das is cool, das nehmen wir für Safari“. Später kam dann Google mit Chrome bzw. Chromium dazu, kopierte Webkit und hat mit Blink „sein eigenes Ding“ gemacht.

Der Einfachheit halber: Wenn ich „Webkit schreibe, meine ich immer Webkit und Blink.

Mittlerweile hat Webkit sehr viele andere Engines Verdrängt. Opera, früher mit den Engines Presto und Elektra sind 2013 auf Webkit umgestiegen. (sind wir ehrlich, Presto und Elektra waren aber auch beschissene Engines. Wenn ich daran denke wie oft Opera Webseiten nicht anzeigen konnte oder Fehler hatte weil die Engine es nicht darstellen konnte…). Mausgestensteuerung und andere Extras wie Mailclient usw. waren allerdings nicht schlecht.

Safari hat schon immer die KHTML/Webkit benutzt, Bleibt nur noch Trinity.

Trinity war oder ist der „Internet Explorer“. Auch diese Engine ist mittlerweile gestorben. Edge, der neue Browser von Microsoft ist mittlerweile auch auf Webkit aufgebaut. Edge Legacy nutzt mit „edgeHTML zwar auch eine eigene Engine, diese basiert wiederum auf einer modernisierten Version von Trinity. Da Edge „legacy“ früher oder später allerdings eh verschwinden wird…

Was bleibt noch übrig?

Mozilla mit der Gecko Engine.

Gecko ist die Rendering-Enginee von Firefox, Seamonkey, Thunderbird, Pale Moon, Waterfox, Cyberfox und diversen anderen, auf Mozilla basierenden Browsern.

Hier eine kurze, aber aufschlussreiche Übersicht über die verschiedenen Browserengines:

https://en.wikipedia.org/wiki/Comparison_of_browser_engines

Hier eine Auflistung der bekannten Webbrowser:

https://en.wikipedia.org/wiki/Comparison_of_web_browsers

Die momentane Verbreitung der einzelnen Engines ist allerdings sehr einseitig. Laut Statcounter ist Chrome, beziehungsweise Webkit weltweit ungeschlagen, und mit weitem Abstand auf Platz 1:

Hier mal ein Paar Zahlen.

Ich habe Alle Browser welche weniger als 0,1% Marktanteil belegen unter „Andere“ zusammengefasst. Hierzu fallen unter anderem Konsolenbrowser (PS4), oder diverse Browser wie Obigo, Openwave oder der AOL Browser, sowie verschiedene Abwandlungen des Firefox oder Chrome Browsers wie Waterfox oder Brave. Mit unter 0,1% Marktanteil würden sie in diesem Artikel ohnehin nicht ins Gewicht fallen:

BrowserEngineMarktanteil in %
ChromeBlink65,89
SafariWebkit16,65
FirefoxGecko4,26
Samsung InternetBlink3,43
OperaBlink2,05
EdgeBlink1,91
UC BrowserBlink1,47
IETrinity1,28
Edge LegacyEdgeHTML0,98
AndroidBlink (Vermutlich)0,48
360 Safe BrowserBlink0,3
QQ BrowserWebkit/Trinity0,29
Yandex BrowserBlink0,27
PuffinBlink0,14
Coc CocBlink0,11
AndereVerschiedene0,49

Aber nun zurück zum Thema.

Zählen wir mal zusammen. Blink und Webkit kommen zusammen auf 92,22% Marktanteil. Hierbei habe ich Den Android Webview Browser und den QQ Browser nicht mit eingerechnet. Gecko kommt auf magere 4,26% Marktanteil, Microsofts Anteil mit Trinity und edgeHTML kommen auf 2,26% – welcher früher oder später ebenfalls zu Webkit/Blink wechseln wird. Bedeutet 1,26% spalten sich auf andere Browserengines auf, wobei Browser wie Waterfox oder Brave welche die Gecko bzw. Blink-Engine benutzen auch unter „Andere“ gelistet sind. (Genaue Daten kann man unter dem oben genannten Link beim klick auf „Statcounter“ oder unten in den Quellenangaben finden).

Warum aber nun dieser LANGE Ausflug in die Statistik? Nun ja. Wenn man über Webbrowser diskutiert, kennt in der Regel selbst der unbedarfteste Benutzer die Namen „Firefox“ und „Chrome“. Das sind in der heutigen Zeit die bekanntesten Browser, deren Namen jeder schon irgendwann einmal gehört hat.

Schaut man sich nur die Verbreitung der Browser auf PCs und Laptops an, ist Mozilla mit etwas über 8% vertreten. Auch keine wirkliche „Größe“.

Warum könnte das ein Problem sein?

Sehen wir es mal von der Seite: Blink/Webkit wird im Gegensatz zu Gecko größtenteils von gewinnorientierten Firmen entwickelt. Namentlich: Google, Facebook, Microsoft, Opera Software ASA, Adobe Systems, Intel, IBM, Samsung, Apple (Webkit) und diversen anderen. Gecko wird größtenteils von Mozilla selbst entwickelt und vorangetrieben. Dass Mozilla, welche sich größtenteils aus Spenden finanzieren, nicht mit Firmen wie Google und Facebook mithalten können was Entwicklungsarbeit angeht, dürfte eigentlich klar sein.

Was haben wir also momentan? Eine Monopolisierung der Browserengine. Ist eine Funktion oder ein Element nicht mit Blink/Webkit kompatibel, wird es auf 92,22% aller Browser nicht, oder falsch dargestellt.

Viele Webentwickler werden sich noch an die Zeiten erinnern in denen man die „IE Browser-weiche“ einbauen musste um bestimmte Elemente kompatibel zum Internet Explorer anzeigen zu können.

Versteht mich nicht falsch, Sollte Blink/Webkit eines Tages 100% Marktanteil erreichen, und es faktisch keine andere Rendering-Engine mehr geben, würde das die Arbeit von vielen Webentwicklern vereinfachen. Man müsste nur eine einzige Engine pflegen, keine Browser-weichen einbauen, nicht 3 verschiedenen CSS-Attribute pflegen… Es würde VIELES vereinfachen.

Allerdings haben wir dann eine Engine, welche von einigen wenigen Firmen gepflegt wird. Und genau das sollte man verhindern.

„Absolute Macht korrumpiert“ – Was hindert diese Firmen daran die Browserengine so umzuschreiben das Telemetriedaten automatisch gespeichert und verschickt werden? Funktionen, die keinen Gewinn bringen werden nicht implementiert. Protokolle, welche nicht den Zielen der Entwickler zuarbeiten werden ignoriert oder nicht eingepflegt.

Es heißt nicht umsonst „Konkurrenz belebt das Geschäft“.

Aber nun zu Mozilla.

4,26%

Als ich angefangen habe diesen Artikel zu schreiben dachte ich mir noch. „Naja, so um die 20 bis 23% Marktanteil wird Firefox schon haben. (In Deutschland allein stimmt das sogar) Immerhin haben die ja einen echt guten Browser.“ Ich selbst nutze… pardon NUTZTE Firefox ja auch schon seit beinahe 16 Jahren. (Firefox 1.0 wurde im November 2004 veröffentlicht) und war bis dato die einzige wirklich brauchbare Alternative zum Internet Explorer. Um so mehr war ich geschockt als ich den weltweiten Marktanteil auf allen Plattformen von unter 5% gelesen hatte. Warum?

Ich bin mittlerweile kein Nutzer von Firefox mehr. Einige Funktionen und Entwicklungen haben mir den Browser gehörig verdorben. – Hier möchte ich ansetzen.

1. Firefox Normandy.

Wer Chrome benutzt, der weis das Google mitliest. Wer Chrome mit einem Google Account benutzt, der weis dass Google die Chrome-Instanz auch beeinflussen kann. Diese Funktion ist besonders für Enterprise-Unternehmen sehr interessant, da man den Browser – ähnlich wie den Internet Explorer und Edge – Innerhalb seiner Firma anpassen kann. Über den „Google Enterprise Admin“ kann man seinen Mitarbeitern einen Chrome zu Verfügung stellen der beispielsweise, eine eigene Startseite hat, oder mit bestimmten Erweiterungen daherkommt. Man kann viele Schräubchen drehen, bis hin zu Black- und Whitelists für bestimmte Webseiten. Allerdings benötigt man dazu eben den Enterprise Admin. – oder einen Google Account. (Wobei ich stark davon ausgehe dass Google auch ohne einen Account auf Chrome Einfluss nehmen kann, aber diese Funktion habe ich (noch) nicht gefunden)

Mozilla hingegen hat „Normandy“. (https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout)

Normandy gibt Mozilla eine umfassende Kontrolle über Firefox.

Was kann Normandy alles verändern? Naja, wenn ich das richtig verstanden habe:

  • Installieren/löschen von Erweiterungen
  • Jedes Flag in „About:config“
  • De-/Aktivieren bestimmter Features

Was mich mehr verunsichert ist, wie detailliert Mozilla dieses Feature anbietet. Man kann diese Änderungen anhand vieler Details ausrollen:

  • Firefox Version
  • Firefox „Kanal“ (Stable, Nightly, Beta)
  • Prozentsatz an Benutzern
  • Land
  • Installierte Sprachdatei
  • Installierte Addons
  • Alter des Profils
  • Anhand bestimmter Werte in der Telemetrie (OS, Ram, Festplatte, Nutzungsdauer, etc)
  • Beliebige Einstellung des Browsers

Was nach einer verdammt guten Funktionalität zum Einsatz in Unternehmen klingt, wäre auch richtig Cool… Wenn es nicht standardmäßig installiert und für alle Benutzer aktiviert wäre.

Das bedeutet: nach einer Standardinstallation hat Mozilla die volle Kontrolle über meinen Browser. Und wenn Mozilla will, kann sich mein Browser auch ganz komisch verhalten. Hier ein Screenshot von einem Frisch installierten, nicht konfigurierten Standard-Firefox ohne eingerichteten Sync-Account nach dem ersten Start:

Ich möchte hier nichts unterstellen, aber ein saurer Nachgeschmack bleibt hier doch hängen. Besonders die Flags „app.normandy.user_id“ und „app.normandy.enabled“ stoßen mir sauer auf.

Keine Nachfrage, kein Hinweis. Still und heimlich wird diese Funktion aktiviert. Eine Funktion welche Mozilla Vollzugriff auf alle Einstellungen, alle Daten und das komplette Profil gibt.

In meinen Augen… Ist das eigentlich ein Musterbeispiel für eine Backdoor.

2. Telemetrie

Ja, Jeder Browser sammelt Nutzerdaten. Dennoch sind in ALLEN Browsern von Mozilla (Mobile, Desktop) Nutzerdaten aktiv. Ich weis nicht ob es ein Fehler in einem Update, ein versehen oder Absicht war, aber bei meinen Firefox Instanzen auf Telefon und Desktop waren die „Sende Nutzungsdaten an Mozilla“ aktiv. Nachdem ich sie abgeschaltet hatte.

3. Tracker

Ich habe mir mal „Pocket“ angeschaut. Besonders deren Datenschutzrichtlinie. Und… nein.

Pocket mag eine nützliche Funktion sein, aber als fester Bestandteil eines Browsers? Sorry, aber ich lasse mich nur ungern tracken.

Dazu die neuesten Änderungen in der Mobilen Firefox Version. Ich möchte hier nicht in einen „früher war alles besser“ rant verfallen, aber was unter anderem abgestellt wurde sind z.B. die Einstellungen unter „about:config“ – vermutlich möchte man nicht mehr das der User in alle Einstellungen eingreifen kann?

Der ‚neue‘ Firefox ist sehr reduziert. Ich habe mich ernsthaft gefragt warum soll ich Firefox verwenden, und nicht doch Fennec?

Ich könnte hier noch einige andere Punkte aufzählen, die allerdings eher persönliche Vorlieben und Abneigungen sind. Z.B. Mozillas permanenter Versuch Chromes ‚Features‘ zu kopieren, nach zubauen und dabei zu verkacken.

Und mal ehrlich, warum soll ich eine schlechte Chrome Kopie verwenden?

Wie schon geschrieben habe ich mich in den letzten Tagen etwas intensiver mit Browsern beschäftigt. Einerseits da ich von Polynomial-C auf Normandy aufmerksam gemacht wurde, andererseits da ich unter Linux eine einfachere Möglichkeit habe Browser zu installieren und zu analysieren. Außerdem musste ich mich nach meiner etwas genaueren Analyse von Firefox ohnehin nach einem neuen Browser umschauen.

Was ich von meinem Browser erwarte?

  • Stabil
  • Schnell
  • Kompatibel mit aktuellen Webtechnologien
  • Datensparsam
  • keine Tracker
  • Eine Synchronisation meines Profils oder eine einfache Backup-Möglichkeit

Die Synchronisation ist hier Nebensache. Unter Linux sollte ein Browserprofil mittels eines recht einfachen Bash-Scripts eigentlich ziemlich einfach zu sichern sein.

Bisher habe ich Firefox verwendet. Einfach nur weil ich kein Chrome nutzen wollte. Neben Firefox hatte ich Chromium. Die Google-freie Version des Chrome Browsers. Allerdings hat Chromium trotzdem die Sync-Funktion von Chrome. Firefox ist aus den oben genannten Gründen keine Option mehr.

Ich nutze in der Regel immer mehrere Browser. Auch um Probleme mit Webseiten abzufangen. Ich versuche daher immer einen Webkit/Blink Browser, einen Gecko Browser und einen „neutralen“ Browser ohne Addons oder Erweiterungen zu behalten.

Ich habe einige Browser ausprobiert. Und bin letzten Endes an Brave und Waterfox hängen geblieben. Waterfox ist ein Fork… nein. Eher ein Derivat von Firefox. Auch wenn Waterfox eine ältere Codebasis von Firefox verwendet, ist Waterfox zumindest ohne Normandy oder andere Tracker. – Noch.

Waterfox hat zwar auch eine Sync-Funktion, welche sich mit Mozillas Dienst abgleicht, aber Ich muss ihn ja nicht benutzen. Mein Profil kann ich immer noch recht einfach mittels Rsync und meinem Homeserver synchronisieren. Gegebenenfalls auch über meinen dedicated Server im Internet.

Brave ist der Browser aus der Webkit/Blink Familie, und hat eine Synchronisierungsfunktion welche ohne zentralen Server auskommt. Man erstellt eine Synchronisierungskette mit mehreren Geräten (Auch Mobilgeräte wie Smartphones und Tablets). DAS fand ich sehr angenehm. Dazu kommt ein Webe und Trackingblocker.

Natürlich (wie sollte es auch anders sein) haben beide Browser auch ihre Schattenseiten. Waterfox wird wohl zum Großteil von einer Werbefirma finanziert. Allerdings hat der Maintainer wohl einen Vertrag geschlossen welcher völlige Freiheiten gewährt. Bisher habe ich zumindest noch keine versteckten Tracker oder andere Überwachungsfunktionen gefunden.

Brave hatte vor einigen Monaten eine Art „Bravegate“. Hierbei hatte Brave bei einigen Links einen Ref-Link angehängt um über Affiliate Partner Geld zu verdienen. Ohne Rückmeldung an ihre Benutzer ein Unding. Allerdings wurde die Funktion deaktiviert. Ein weiteres cooles Feature: Alles was man Braucht um Brave selbst aus dem Chromium Projekt zu erstellen stehen im Brave Git öffentlich zur Verfügung.

Hier noch ein kleiner Nachtrag den ich erst später gefunden habe. Ein Video welches die Browserverteilung mal visualisiert darstellt. (Herzlichen dank an den Pie Chart Pirate)

Quellen:

Mozilla… What the fuck is wrong with you? Weiterlesen

MFA über SSH auf Arch/Manjaro

Heute habe ich meinen Jumpserver neu aufgesetzt. Das ist eine kleine VM auf meinem Homeserver der mit einem Bein in meinem internen Netzwerk, mit dem anderen Bein im Internet steht. Über den Jumpserver komme ich von außen auf alle Maschinen in meinem internen Netzwerk, und von meinem internen Netzwerk auf alle Maschinen im Internet, die ich betreue.
Das ganze ist kein Proxy, sondern eigentlich nur ein SSH-Jumphost… Bei dem ein Wireguard-VPN ins Rechenzentrum läuft. Ohne Wireguard, keine SSH Verbindung zu den Maschinen. (Und kein Zugang zum Firewall-UI… und zur Management-Konsole… und so ziemlich zu nichts administrativen…)

Wie dem auch sei. Mein alter Jumphost lief auf einem Debian dass ich seit Version 4 oder 5 immer nur wieder aktualisiert habe. In der letzten Zeit gab es da so ein paar Problemchen, weswegen ich den Jumpserver neu aufsetzen wollte. Diesmal aber mit einem Arch Linux als Unterbau.

Die Grundinstallation von Arch möchte ich hier nicht breit treten, denn dafür gibt es eine ganze Reihe von Anleitungen, inklusive der im Arch-Wiki. Einzig eine Netzwerkverbindung nach der Installation und das automatische Verbinden beim Systemstart hat mich ein bisschen beschäftigt.

Was mich mehr interessiert hat, war der Login via SSH. Ich wollte neben Fail2ban eine Multi-Faktor-Authentifizierung (MFA) haben. Was eine MFA ist, ist recht schnell erklärt. Es gibt mehrere Faktoren um einen Login zu ermöglichen:

  • Etwas das man weiß (Wissen)
  • Etwas das man ist (Idendität)
  • Etwas das man hat (Besitz)
  • (neue Definition) Standort

Man spricht von „Multi-Faktor“ sobald zwei oder mehr dieser Merkmale bei einem Login abgefragt und geprüft werden. Da ich den Standort wechsle, manchmal mit meinem Smartphone oder Laptop von unterwegs, manchmal von meinem Homerechner aus mich auf meinem Jumpserver einlogge ist der Ort als Verifikation unbrauchbar. Sollte man denken, aber der Ort wird später noch wichtig. Was ich wollte war „Wissen“ und „Besitz“ – also eine klassische „Zwei-Faktor-Authentifizierung“ (2FA). Also einen Usernamen und Passwort (Wissen) und einen Token (Besitz). Aber ich bin faul. EXTREM faul. Ich bin so faul dass ich keine Lust habe, jedesmal bei einem Login mein Smartphone herauszuholen und einen sechsstelligen TOTP-Key abzutippen. (TOTP = Timebased One Time Password). Darum habe ich einen Yubikey. Den will ich verwenden. (Anmerkung, Mein Yubikey ist auf „Yubikey-OTP“ konfiguriert)

Aber was wenn ich den mal vergesse oder verliere? Ok. Als backup will ich dann eben doch TOTP. Zum Glück ist das Linux. Da sollte das möglich sein.

Zuerst installiere ich mein ARCH base System. Das geht recht schnell und mein System läuft. Anschließend installiere ich noch einige System-tools wie den Midnight Commander und diverse Packprogramme. Auch die dnsutils, net-tools und natürlich yay dürfen nicht fehlen. Yay ist der Paketmanager für AUR (Arch User Repository). Anschließend installiere ich die Bibliotheken für den Yubikey und den TOTP-Mechanismus.

yay -Syyu
yay -S yubico-pam google-authenticator-libpam-git

Danach muss ich zuerst mein PAM (Pluggable Authentication Modules) und die SSH-Demon config ein bisschen tweaken. Am einfachsten ist hier die SSH-Config. Da ich hier ohnehin noch einige Feineinstellungen machen wollte fange ich hier an. Doch zuerst öffne ich eine kleine SSH-Sitzung welche ich aktiv lasse und minimiere. Sollte ich einen Fehler machen und mich nicht mehr einloggen können, ist das mein Backup. Für MFA benötige ich hier eigentlich nur die fett markierte Zeile. Der Rest ist allgemeines „Feintuning“:

Port 22
HostKey /etc/ssh/ssh_host_ed25519_key
PermitRootLogin no
MaxAuthTries 3
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes
PermitEmptyPasswords no
UsePAM yes
AllowAgentForwarding yes
AllowTcpForwarding yes
X11Forwarding no
TCPKeepAlive yes
ClientAliveInterval 300
ClientAliveCountMax 2
ChallengeResponseAuthentication yes
Banner /etc/ssh/bannet.txt
Subsystem sftp /usr/lib/ssh/sftp-server
AllowUsers arsimael

Nach einem „systemctl restart sshd“ sind die änderungen aktiv. Nun muss ich meine PAM Regeln bearbeiten. Da ich nur die SSH-Verbindungen absichern möchte, bearbeite ich hierzu die /etc/pam.d/sshd:

So sieht die Datei im Originalzustand aus.
Ich füge folgende Zeile am Ende hinzu:

auth [new_authtok_reqd=ok default=ignore] pam_yubico.so id=16 nullok

Nun speichere ich ab. Ich muss meinen Yubikey als erlaubt hinterlegen. Dazu erstelle ich einen Ordner in meinem home -Verzeichnis mit dem namen „.yubico“ und lege dort eine Datei „authorized_yubikeys“ an und vergebe die entsprechenden Rechte:

mkdir .yubico
chmod 700 .yubico
touch .yubico/authorized_yubikeys
chmod 600 .yubico/authorized_yubikeys

Ich öffne die authorized_yubikeys Datei und stecke meinen Yubikey an. Ich drücke in paar mal den Button und sehe mir die erzeugten Passwörter an. Die ersten zwölf Zeichen sind immer dieselben. So wie es in der Yubikey-Doku beschrieben ist, lösche ich alles danach und weise diese Zeichenfolge meinem Benutzer zu:

Nach dem speichern versuche ich einen Login auf dem Jumpserver, und voilá:

Ich stecke meinen Yubikey ein, drücke den Button und der Login ist komplett. – DAS funktioniert also schonmal.

Aber was wenn ich meinen Yubikey verliere? Oder wenn dieser gestohlen wird? Ich möchte ein backup, eine Alternative zum Yubikey. Hier kommt mir TOTP in den Sinn. Zeitbasierte Einmal-passwörter. Wie man sie bei beinahe jedem gut eingerichtetem Webservice nutzen kann. „Wenn andere das können, kann ich das auch.“

Ich mache mich auf die Suche, und die einfachste Methode scheint hier wohl der „google-authentikator“ zu sein. Obwohl diese Library von Google ist, nimmt sie (angeblich) keine Verbindung zu Google-Servern auf, sondern stellt lediglich die Funktionen zur verfügung, welche ich nutzen möchte. Das authentifizieren via Einmal-kennwörter.

Die Installation habe ich oben schon erledigt. Die Integration in pam stellt laut offizieller doku auch kein Problem dar. Ich passe meine /etc/pam.d/sshd Direktiven ein weiteres mal an:

Da ich ZUERST nach meinem Yubikey gefragt werden möchte, und nur im Falle dass ich den Yubikey nicht habe nach dem TOTP Passwort gefragt werden möchte, passe ich die Yubikey direktive an und sage „Wenn der Yubikey eingegeben wurde, frage nicht weiter sondern erlaube den login“ (success=done).

Danach muss ich meinen TOTP einrichten. Das geht recht angenehm mittels dem Commandline Tool „google-authenticator“ (einfach als user den man einrichten möchte Ausführen)

Anschließend teste ich die neue Konfiguration und es funktioniert.

Tweaks/Tricks – oder „Wo der Standort eine Rolle spielt“:

Ich habe jetzt eine MFA Authentifizierung auf meinem Jumpserver. Aber ich habe oben schon erwähnt: Ich bin faul. Ich habe keine Lust jedesmal meinen Yubikey heraus zu suchen wenn ich ZUHAUSE (also in meinem eigenen, sicheren und vertrauensvollen Netzwerk) bin.

Das muss sich auch orgendwie regeln lassen. Und das geth auch. Ich lege eine neue Datei an: /etc/ssh/ssh-pamrules.conf und definiere mein eigenes Heimnetz als „erlaubt“:

Der Hierarchie nach:

  • ERLAUBE ALLES VON 10.0.0.0/8
  • ERLAUBE ALLES LOCAL
  • VERBIETE ALLE

Ich erlaube demnach Verbindungen aus meinem Heimnetzwerk und von local – also von meinem Server auf sich selbst, und verbiete den Rest.

Diese Regeln müssen pam nun noch mitgeteilt werden. Dazu modifiziere ich meine /etc/pam.d/sshd wie folgt:

Wichtig idt die Reihenfolge. Der gesamte obere part sorgt dafür dass ich regulär nach meinem Passwort gefragt werde. Danach prüft er ob ich mich in meinem eigenen Netzwerk befinde (Standort). Trifft diese Regel zu, darf ich mich einloggen (success), stimmt das nicht, muss ich entweder meinen Yubikey, oder meinen TOTP verwenden.

Selbstverständlich sollte trotzdem bei ALLEN Servern im Netz fail2ban installiert sein.

MFA über SSH auf Arch/Manjaro Weiterlesen