Messages

@mimugmail: Siehst du eine Chance, dass das offiziell auch in der Community Version aufgenommen wird, wenn man entsprechend eine Copy&Paste-ready Lösung zur Verfügung stellt?

@Monvievh: Sorry, mache das beruflich ;-). Nur statt IT im Bereich Automotive mit Automobilhersteller und -zulieferer.

Hallo Monviech, hallo meyergru,

danke euch für die Rückmeldungen und den Input aus den GitHub-Tickets! Ich möchte gerne auf eure Punkte eingehen und erklären, warum ich mich im Rahmen der TARA-Analyse (Threat Analysis and Risk Assessment) klar für ein einziges Formular mit separaten Feldern (Username, Passwort, OTP/TOTP) und gegen ein zweistufiges Verfahren (Two-Step Login) ausspreche:

1. Ein Formular (Combined Form) vs. Zwei Formulare (Two-Step Login)

Ein zweistufiges Verfahren (erst User/Passwort, danach bei Erfolg OTP-Abfrage) birgt im Sicherheitskontext gravierende Nachteile:

- Sicherheitsrisiko "State-Handling": Sobald nach Schritt 1 das OTP abgefragt wird, muss der Server im Backend einen "Teil-Authentifizierungs-State" (z. B. via Session/Token) verwalten. Das schafft eine Angriffsfläche für Session-Hijacking oder State-Bypassing, bevor die eigentliche 2FA überhaupt vollständig abgeschlossen ist.

- Information Leakage / User Enumeration: Wenn erst nach richtiger Passwort-Eingabe das OTP-Feld erscheint, erfährt ein Angreifer sofort, dass das Passwort korrekt war. Bei einem einzigen Formular schlagen falsches Passwort, falscher TOTP-Code oder ein fehlender Code immer in demselben "Invalid credentials"-Fehler fehl.

- Gleicher Schutz ohne UX-Bruch: Wenn das OTP-Feld immer präsent ist (oder optional per UI eingeblendet werden kann, ohne Rückmeldung über Passwort-Gültigkeit zu geben), gibt es keinerlei Information Leakage über den Validierungsstatus des ersten Faktors.

2. "Bisher keine Angriffe beobachtet" ist kein Sicherheitsargument

Dass gewisse Angriffe auf OPNsense-Instanzen bisher vielleicht nicht prominent beobachtet wurden, ist kein Beleg für deren Abwesenheit oder eine Entwarnung für die Zukunft:

- Der Markt verändert sich drastisch: Derzeit sehen wir eine massive Welle von automatisierten, hochskalierten Angriffen auf kommerzielle Firewall- und VPN-Lösungen (Cisco, Fortinet, Ivanti etc.). Da Open-Source-Lösungen wie OPNsense im Enterprise-Umfeld immer beliebter werden, rücken sie automatisch stärker in den Fokus professioneller Angreifer.

- Timing-Attacks & Enumeration sind Standard: Automatisierte Botnets testen heute routinemäßig auf Timing-Unterschiede und Enumeration-Lücken, um gültige Konten vorab zu filtern, bevor der eigentliche Brute-Force-Angriff startet.

3. Zu den drei spezifischen Backend-Punkten

- Timing-Schutz (User Enumeration): Ein generisches sleep reicht oft nicht aus, wenn der Pfad für "User existiert nicht" signifikant schneller fehlschlägt als "User existiert, aber Passwort falsch" (z. B. wegen des kryptografischen Hashing-Oversize bei BCPrypt/Argon2). Hier ist ein konstanter Laufzeit-Pfad im Backend essenziell.

- DoS / Rate-Limiting: Die Einbindung ins Firewall-Alias (z. B. via sshguard / blocklist) ist super, greift aber oft erst nach N Fehlversuchen auf IP-Ebene. Ein frühes Rate-Limiting direkt auf Applikationsebene schützt das Backend davor, dass teure Hash-Funktionen die CPU der Firewall lahmlegen.

- Replay-Schutz für TOTP: Da TOTP-Tokens innerhalb ihres 30-Sekunden-Fensters mathematisch valide bleiben, sind sie anfällig für kurzfristige Replay-Angriffe (z. B. abgefangen via Man-in-the-Middle / Phishing-Proxies wie Evilginx). Ein einfaches Cache-Register im Backend, das bereits verwendete TOTP-Tokens für deren Gültigkeitsdauer speichert und ein zweites Mal ablehnt, eliminiert diese Lücke vollständig – unabhängig vom Betriebssystem-Zustand.

Mir geht es absolut nicht darum, das System unnötig zu verkomplizieren oder den Komfort einzuschränken. Die Implementierung einer sauberen Backend-Logik mit einem integrierten OTP-Feld verbessert sowohl die UX (Passwort-Manager Support) als auch die Härtung gegen moderne Angriffsmuster massiv.

VG
jd

Hallo meyergru,

danke für die Links, die Tickets kannte ich noch nicht!

Mir geht es hier allerdings weniger um das UI, sondern primär um die Backend-Härtung aus der TARA-Analyse:

- Timing-Schutz gegen User-Enumeration
- DoS-Schutz durch frühes Rate-Limiting
- Replay-Schutz für benutzte TOTPs

Das UI-Feld ist nur die logische Folge der überarbeiteten Backend-Logik.

Da das Thema in den alten Tickets bisher nicht umgesetzt wurde: Besteht an einer solchen Backend-Härtung überhaupt Interesse, und ist eine Unterstützung hier gewünscht?


Vg
Jd7

Hallo zusammen,

ich nutze OPNsense schon seit einigen Jahren und schätze die integrierte 2FA sehr. Allerdings empfinde ich das Anfügen des OTP-Tokens an das Passwortfeld in der Praxis als etwas umständlich.

Ich habe mir daher Gedanken über ein zusätzliches, eigenes Eingabefeld für den 2FA-Code auf der Login-Seite gemacht.

Damit das Ganze Hand und Fuß hat, habe ich dafür eine Sicherheits- und Risikoanalyse (TARA) durchgeführt. Der Vorteil einer solchen systematischen Überprüfung ist, dass dabei nicht nur das neue UI-Feld betrachtet wird, sondern auch direkte Sicherheitsgewinne für die gesamte Log-in-Logik abfallen:

* Schutz vor Timing-Angriffen: Die Antwortzeiten verraten nicht mehr, ob ein Benutzer existiert oder ob 2FA aktiv ist.
* DDoS-Schutz fürs WebUI: Blockaden (Rate Limiting) greifen, bevor rechenintensive Passwort-Prüfungen das System belasten.
* Keine Token-Wiederverwendung: Bereits genutzte OTP-Codes werden sofort für die weitere Verwendung gesperrt.
* Saubere Log-Einträge & Absicherung: Besserer Schutz gegen Log-Fälschungen und fehlerhafte Fehleingaben.

Im Anhang findet ihr die TARA-Analyse sowie einen beispielhaften PHP-Code-Prototypen.

Wie seht ihr das? Wäre ein separates Feld inkl. dieser Backend-Anpassungen aus eurer Sicht ein Mehrwert oder eher unnötiger Aufwand für die Entwicklung?

Ich freue mich auf euer Feedback!

Viele Grüße
jd

Thanks for your explanation! Nothing is perfect. I try to better understand opnsense and hopefully help to improve it in future.

First, before I generated manually the files with dhparam, I tried to reinstall the plugin, but it doesn't worked.

After your proposal to press "apply", the nginx.conf changed:

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_dhparam /usr/local/opnsense/data/OPNsense/Nginx/dh-parameters.4096.rfc79
19;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_prefer_server_ciphers on;
    ssl_stapling off;

and now I can find dh-parameters.4096.rfc79 in the path above and it still works ;-)

My approach also worked, but I tried to understand whats going wrong. As I know see, that after an update I have to press "apply" to every service to reload changed templates?

I think I started with a clean installation of 21.1. Since them I always used the update mechanism from the webui. It worked since the upgrade to 22.7. Here is the output of the health check.

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.7.3_2 (amd64/OpenSSL) at Tue Sep  6 11:05:03 CEST 2022
>>> Check installed kernel version
Version 22.7.3 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.7.3 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-clamav 1.7_1
os-dmidecode 1.1_1
os-git-backup 1.0_3
os-haproxy 3.11
os-iperf 1.0_1
os-nginx 1.29_1
os-postfix 1.23_2
os-redis 1.1_1
os-rspamd 1.12
os-smart 2.2
os-theme-cicada 1.29
os-wireguard 1.12
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 63 dependencies to check.
Checking packages: ................................................................. done
***DONE***

After upgrading from 22.1.10_4-amd64 to 22.7.3_2-amd64 the nginx update broke the current setup. After restarting the nginx server, I continously got the error:

Code Select Expand

"BIO_new_file("/usr/local/etc/dh-parameters.4096") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/etc/dh-parameters.4096','r') error:2006D080:BIO routines:BIO_new_file:no such file)"

After looking via shell to the nginx.conf file and the file dh-parameters.4096, I found out that all dh-parameters.<keysize> files are missing.

After generating these files with:

Code Select Expand

/usr/bin/openssl dhparam -dsaparam -out /usr/local/etc/dh-parameters.1024 1024
/usr/bin/openssl dhparam -dsaparam -out /usr/local/etc/dh-parameters.2048 2048
/usr/bin/openssl dhparam -dsaparam -out /usr/local/etc/dh-parameters.4096 4096

and restarting nginx, I seems to work.

Any ideas why this have to be done manually after upgrading?

Perfect. Thanks!

br,
Jochen

Thanks! That was the problem. It use the same entry in the menu bar. Both use Dynamic DNS.

br,
Jochen

Hi Franco,

If I compare the settings from 21.7 with 22.1, see also https://docs.opnsense.org/manual/dynamic_dns.html. I only get a few options for configuration.

Br,
Jochen

Hi,

we used os-dyndns in the release 21.7. with "custom options" for strato. As far as I see it is not possible anymore?

br,
Jochen

Kann mir jemand einen Tip geben, wie man Plugins entwickelt bzw. bestehende Plugins erweitern kann? Ein Hinweis auf ein Tutorial würde mir sehr helfen. Vielen Dank im Voraus.

Ich habe hierzu ein Ticket angelegt: https://github.com/opnsense/plugins/issues/1926