Plesk 17.8.11 Update 56 und PHP 7.2.19

Die mit dem Plesk Onyx Update 17.8.11 #56 ausgelieferte PHP Version 7.2.19 hat scheinbar Probleme.

Nach dem automatischen Update von Plesk lief der Blog hier ein wenig holprig bis gar nicht. 🙁 In den Logfiles gab es diverse Fehler bzgl. der Speicherallokierung und WordPress lieferte nur eine leere weiße Seite.

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 7146776576601513112 bytes) in C:\Inetpub\vhosts\jans.cloud\httpdocs\wp-includes\option.php on line 1247

php_error

Kurzfristig „half“ es die Website im IIS neu zustarten bzw. den IIS neu zustarten. Nach ein wenig Recherche brachte das deutsche WordPress Forum licht ins Dunkel. Scheinbar gibt es in der aktuellen Plesk Onyx Version Probleme mit der darin enthaltenen PHP Version. Somit läuft jans.cloud derzeit mit der PHP Version 7.1.30.

Firefox Add-Ons und Plugins deaktiviert

Alter Add-On-Typ: Diese Erweiterungen erfüllen nicht die aktuellen Standards von Firefox und wurden deshalb deaktiviert. Weitere Informationen über Änderungen bei der Unterstützung von Add-Ons für Firefox.

Da schaltet man am Samstag den PC ein und stellt fest, dass alle Firefox Add-Ons bzw. Plugins deaktiviert wurden. Da hat der Herr Mozilla anscheinend vergessen ein Zertifikat zu verlängern, welches die Add-Ons prüft:

https://twitter.com/mozamo/status/1124484255159971840

Das eigentliche Sicherheitsfeature zur Überprüfung der Plugins sollte sich im „about-config“ des Mozilla Firefox‘ deaktivieren lassen. Dazu in der Adresszeile about:config öffnen und nach „xpinstall.signatures.required“ Suchen sowie den Wert von „true“ auf „false“ stellen. Ich würde es allerdings nicht machen, da der Fehler wohl schnell behoben werden sollte. BTW. hilft das Ändern von „xpinstall.signatures.required“ nur bei den Nightly und/oder Developer Versionen des Firefox‘.

Weitere „Infos“ neben Twitter auch im Mozilla Forum: (https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/1), sofern es erreichbar ist ;):

Mozilla Too Many Requests
Mozilla Too Many Requests

Ein kleines Update aus dem Mozilla Forum von kurz vor 13 Uhr:

12:50 p.m. UTC / 03:50 a.m. PDT: We rolled-out a fix for release, beta and nightly users on Desktop. The fix will be automatically applied in the background within the next few hours, you don’t need to take active steps.
In order to be able to provide this fix on short notice, we are using the Studies system. You can check if you have studies enabled by going to Firefox Preferences -> Privacy & Security -> Allow Firefox to install and run studies.
You can disable studies again after your add-ons have been re-enabled.
We are working on a general fix that doesn’t need to rely on this and will keep you updated.

https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/14

Wer also in den „Einstellungen“ -> „Datenschutz & Sicherheit“ -> „Datenerhebung durch Firefox und deren Verwendung“ den Haken bei „Firefox das Installieren und Durchführen von Studien erlauben“ gesetzt hat, kann jetzt bereits wieder mit seinen Add-Ons loslegen. Alle anderen müssen noch ein wenig Geduld haben. Ggfs. den Haken kurz setzen, „patchen“ und Haken wieder entfernen. 🙂

Firefox das Installieren und Durchführen von Studien erlauben
Firefox das Installieren und Durchführen von Studien erlauben

Noch ein Update zum Extended Support Release (ESR) Kanal:

Gestern, am 05.05., hat Mozilla dann noch die 60.6.2 mit dem passenden Fix für den Firefox ESR Kanal veröffentlicht: https://www.mozilla.org/en-US/firefox/60.6.2/releasenotes/

Windows Login mit Mehr-Faktor-Authentifizierung absichern

Im dritten Part zur Mehr-Faktor-Authentifizierung (Part I / Part II) geht es um den RCDevs OpenOTP Credentials Provider zur Absicherung des Windows Logins mit einem weiteren Faktor / One Time Password.

Damit der Windows Login mit einem entsprechendem zweiten Faktor geschützt werden kann, muss als erstes der passende Credential Provider heruntergeladen werden:

Weiter geht es mit der Installation des OpenOTP Credential Provider. Dazu das entsprechende ZIP entpacken und das MSI Paket per Doppelklick öffnen:

  • Der „Welcome Screen“ wird mit „Next“ bestätigt
  • Die EULA wird natürlich gelesen und akzeptiert -> „Next“
  • Für den ersten Test empfiehlt es sich den „Default provider“ nicht zu installieren -> „Next“
  • Im nächsten Step den Primary Server mit „https://<IP / FQDN der Appliance>:8443/openotp“ konfigurieren und evtl. den „Request Timeout“ anpassen -> „Next“
  • Authentication Form
    • Simple: Erst werden Benutzername und Passwort eingegeben; Im nächsten Schritt der zweite Faktor
    • Normal: Auf dem Anmeldebildschirm gibt es drei Felder (Benutzername, Passwort und Einmalpasswort)
  • Die ersten „Advanced Settings“ können mit den Standardeinstellungen übernommen werden -> „Next“
  • Die zweiten „Advanced Settings“ sollten ggfs. angepasst werden, damit ebenfalls der RDP Zugriff geschützt wird bzw. ein Offline Login* (z.B. am Notebook) ermöglicht werden kann -> „Next“
  • „Install“ -> „Finish“

*Offline Login: Damit der Offline Login am Notebook funktioniert müssen zwei Bedingungen erfüllt sein!

  1. Es müssen „Push Tokens“ genutzt werden!
  2. Eine Anmeldung muss „online“ mit erreichbarem OpenOTP Server erfolgen!

Damit der erste Test durchgeführt werden kann, muss sich vom System abgemeldet werden. Nach erfolgter Abmeldung begrüßt uns der „OpenOTP Login“. Wie an dieser Stelle zu sehen ist, macht es später in einer produktiven Umgebung wenig Sinn den „Default provider“ zu deaktivieren. Ein Klick auf „Anderer Benutzer“ würde reichen, um sich ohne den zweiten Faktor anzumelden.

Damit sich an diesem Server / dieser Workstation nur noch per Multi-Faktor-Authentifizierung angemeldet werden kann, muss die Installation angepasst werden und der „Default provider“ installiert werden. Dazu die installierten Programme- und Features anzeigen, den „OpenOTP-CP“ Einträg wählen sowie auf „Ändern“ klicken. Jetzt wird lediglich der „Defaul provider“ aktiviert. Der Rest der Konfiugration bleibt identisch. Was passiert hier? Der folgende Registry Schlüssek wird angelegt und der „Standard Key“ auf den OpenOTPCredentialProviderFilter gesetzt:

Windows Registry Editor Version 5.00


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters{5AE8C610-7541-4FF8-9845-C363410D574C}]
@=“OpenOTPCredentialProviderFilter“

Registry

Ab diesem Zeitpunkt sind nur noch Anmeldungen mit registrierten OpenOTP Usern möglich! Um den „Default provider“ wieder zu deaktivieren, reicht es aus den o.g. Registry Schlüssel zu löschen. Z.B. per Gruppenrichtlinien Registry Einstellung. Computer Startu-Up Script oder im abgesicherten Modus. Um die Änderung des „Default providers“ auch im abgesicherten Modus zu deaktivieren, muss ein weiterer Registry Key gesetzt werden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers]
„ProhibitFallbacks“=dword:1

Registy

Aufgehoben wird das Erzwingen des „Default providers“ mit folgendem Schlüssel erneut z.B. per GPO Registry Einstellung oder Computer Start-Up Script:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers]
„ProhibitFallbacks“=-

Registry