Messages

That is perfectly possible, but see #24.

I have to make three corrections to formerly discussed points, though:

1. PCIe actually has its own mechanisms for data-integrity protection between the card and CPU/chipset: LCRC with link-level replay can detect and recover transmission errors, ECRC can provide additional end-to-end error detection, and AER can report PCIe errors.
This means that the observed data corruption may have occurred somewhere outside the portion protected by PCIe's link-level CRC/replay mechanism.

2. The X570S chipset was formerly believed to be different from the X570, yet there is no proof of that. On the contrary, ASRock said it was only fine-tuning that made passive cooling possible. Other manufacturers made claims to this as well.

3. In the meantime, my counter-proof to the PCIe initialisation on warm boots was contradicted - see: https://github.com/torvalds/linux/commit/ae1737e7339b513f8c2fc21b500a0fc215d155c3 and https://bugzilla.kernel.org/show_bug.cgi?id=220770

Maybe this was an implementation fault in either the Windows driver, defective NICs or bad board layout on Asrock's behalf - I cannot tell nor investigate, because I do not have the cards any more. All I can say is that the problems existed and were solved by switching to the other NIC - which also has the advantage of being able to fully use 10 GbE over my 17m CAT5 link, which could not reliably be achieved with either an X550 or X540 before.

On a side note: chalk those inaccuracies up to my discontent about having to investigate such problems for weeks when I just wanted to have more speed on my main workstation.

[alle]

@jd7: Mich musst Du nicht überzeugen. Ich bin klar für ein TOTP-Feld, dass immer angezeigt wird (aber bei nicht aktiver TOTP nicht gefüllt werden muss). Alle anderen Dinge - richtig implementiert - sind sicherheitstechnisch sinnvoll.

Auf der anderen Seite glaube ich, dass die Fehlermeldungen alle Möglichkeiten beinhalten sollten, ohne die spezifische Ursache (User nicht vorhanden / Passwort falsch / OTP (oder Uhrzeit) falsch / DoS erkannt) zu benennen. Aus Abwägung bzgl. Useability würde ich eventuell sogar die Uhrzeit und das Datum in der Fehlermeldung anzeigen. Und selbst dann würden nach Einführung der Änderung Diskussionen und "dumme" Fragen hier im Forum die Folge sein.

Und wie gesagt: AFAIK, geht im Augenblick nur TOTP für alle oder für keinen - das würde ich so belassen. OWASP empfiehlt MFA für alle Benutzer und ausdrücklich verpflichtend für administrative bzw. privilegierte Accounts. Ja - man könnte für weniger priviligierte Accounts auch TOTP-freien Zugang erlauben, nur ist die Realität, dass das Anwender genau nutzen würden, um einen "Reserve"-Root-Account zu haben, der auch bei falscher Uhreinstellung den Login garantiert.

Beiseite gesprochen sollte der Admin-Zugang firewalltechnisch sowieso nur von vertrauenswürdigen Quellen aus zugänglich sein. Echte Angriffsszenarien sind also hoffentlich eher selten.

Du kannst ja erstmal gucken, ob die OpnSense selbst die Requests macht oder ob sie von einer Schnittstelle hereinkommen.

Ich schickte die Tickets wegen der darin enthaltenen Diskussionen und den darin enthaltenen Punkten, die Deine Analyse noch nicht enthält.

Der primäre Grund für das Auseinanderziehen der Eingabefelder wäre a.m.S. die Möglichkeit, das standardkonform mit Passwort-Managern machen zu können. Es wurde dagegen ins Feld geführt, dass man, wenn das in Abhängigkeit von 2FA ein/aus gemacht wird oder sogar, wenn man das Feld immer mit anzeigt, man auf die OpnSense-Version rückschließen kann.

Das ist im ersten Fall richtig, im zweiten falsch bzw. irrelevant, weil man aufgrund der JS/CSS-Dateien sowieso den Versionsstand profilen kann, also ist das kein Argument dafür oder dagegen.

Was die Replay-Attacken angeht, bin ich unschlüssig. TOTP ist inhärent kein Mechanismus, der dagegen schützt, was einer der Gründe ist, wieso es für PSD2 nicht zugelassen ist. Man könnte das zusätzlich einbauen, um gegen Man-In-The-Middle-Attacken zu schützen, die den Login abgreifen und zeitnah ein zweites Token holen.

Ich würde sagen, dass benutzerselektives TOTP das Verfahren als solches unterläuft. Ganz oder gar nicht.

Die anderen Hinzufügungen sind m.E. auch sinnvoll, allerdings muss man sagen, dass der Komfort bei allen diesen Dingen leidet. Nimm als Beispiel das Verstecken des Grundes für das Misslingen: Da könnte sich ein User aussperren, weil die Uhrzeit auf der OpnSense nicht stimmt.

Man müsste hier streng darauf achten, dass der Grund für die Ablehnung quasi nie offengelegt wird. Es wurde ja auch diskutiert, dass man das TOTP-Feld erst nach korrekter Passwort-Eingabe anzeigt - geht aus genau dem Grund nicht. Andererseits würde das Hinzufügen des Eingabefelds viele User verunsichern...

Mein Eindruck war, dass das ganze Thema bei Deciso insgesamt nicht auf großes Interesse stößt... es gab schon mal Patches, die aber nicht berücksichtigt wurden (ich kenne aber die konkreten Gründe nicht).

https://github.com/opnsense/core/issues/8239

https://github.com/opnsense/plugins/issues/5592

Ich kann da nur vermuten... Es sieht so aus, als würdest Du nicht (nur) Unbound verwenden, sondern einen eigenen DNS-Server.

Das Problem, was Du beobachtest, dürfte irgendein stündlicher Cron-Job sein, der Logeinträge auswertet und dazu DNS-Auflösungen für die gefundenen IPs macht, die vermutlich zu großen Teilen in RFC1918 liegen. Das könnten z.B. per VPN verbundene Subnetze sein oder auch IPs, die von irgendeinem Client kontaktiert werden und gar nicht lokal existieren.

Viel wahrscheinlicher ist aber, dass Du Reporting → Settings → Unbound DNS reporting → Statistics aktiviert hast. Dadurch wird stündlich eine Unbound-Log-Auswertung gemacht - aber nicht per Cron.

Wenn diese nicht vom DNS-Server aufgelöst werden können, wird er upstream nachfragen, solange niemand das blockt, d.h. die Anfragen gehen eventuell sogar über Deinen uplink raus.

Das Verhalten hängt u.a. auch davon ab, wie "Do not use the local DNS service as a nameserver for this system" gesetzt ist.

Unbound hat, um das zu verhindern, bereits 10.in-addr.arpa., 16.172.in-addr.arpa. bis 31.172.in-addr.arpa. sowie 168.192.in-addr.arpa. als eingebaute AS112-/Local-Zones. Nicht lokal bekannte PTRs werden dort mit NXDOMAIN beantwortet und nicht rekursiv bzw. an einen Catch-all-Forwarder weitergereicht. Das ist ausdrücklich dazu gedacht, Leaks privater Reverse-Lookups zu verhindern.

Da Du aber gleichzeitig offenbar die Requests alle an deinen eigenen DNS-Server richtest, landen die PTR-Requests eben dort und ggf. sogar irgendwo weiter draußen.

No problem here, neither with opening the site in Edge nor with the given command - it returns 200.

So that is not an OpnSense problem. I would rather suspect a geoip issue, because Youtube has distributed servers. You may have hit a defective one.

Yes, and ironically, NetworkChuck gave the root API key to the AI agent... :-(

Well, before that he bought a chinese box with RealTek NICs, so what could we expect?

[unsolvable trust problem]

1. I hope you are aware of one unsolvable trust problem once the models or # of tokens get too big to handle with a local LLM: Even if you limit the model to read-only access and implement user safeguards a.s.o.: the user must still trust big tech by using their AIs.

Keep in mind, that there are lots of sensitive data in the firewall configurations, ranging from VPN keys to potentially, CA private keys.
To see where I am going with this, just read this in a similarly sensitive context - the author of that tool does either not comprehend of what he is doing or he really is a sock-puppet (also, at the time he first presented his project, he had no verifiable history in the tech community). He even claims that his tool is "The Proxmox MCP you can hand the keys" - yet all of his attempts are futile in that he is neither an expert in Proxmox nor AI models and he cannot even program himself (all is done by Claude).

I sure hope you do not fall for the same misconceptions.

2. That being said, your links do not work at this time. I always get a 404, so I cannot verify or try out anything you have done - I would never do that on a production machine, BTW and urge others to apply the same caution. There have been attempts lately to lure unaware OpnSense users into installing tools on their boxes, up to creating a facade company website with a catchy name. So, I also hope the moderators are closely watching this.

By now, I would say: Let's not AI OpnSense if the MCP server is implemented in a way that makes non-local LLMs neccessary or needs anything installed on the box itself. I know that is a high hurdle, but hey!

I think you misinterpret that: The color green stands for the UP state, the square is the button for stopping the service. This is the same as with most audio equipment, like tape decks or CD players.

You are right, the public key I gave was for Germany only. I corrected the first post accordingly.

If a previous boot keeps the machine from crashing, I would still update the boot loader just for testing. AFAIU, the old one created memory corruptions.

Could that also have to do something with the old, buggy bootloader that triggered the os-microcode bug in the first place?

I updated all bootloaders beforehand and saw no problems on any system I upgraded.

Or you should take a look at the release notes?

Especially where it reads:

o The CPU microcode early loading has been known to be flaky on some setups.  A fix is in the FreeBSD 15.1 boot loader code, but can only be reached by reinstall or manually updating the boot code of your system after the upgrade succeeded.  If you want to be on the safe side during the upgrade itself please remove the plugin before proceeding.

And then there is this.

Merke: Bei Firewall-Regeln gibt es kein Sicherheitsnetz! Die müssen schon stimmen, d.h. man sollte wissen, was man tut.

Jede Allow-Regel zu viel kann Traffic passieren lassen, den man nicht wollte und jede Block-Regel zu viel kann Traffic blockieren, den man dringend benötigt hätte (deswegen ist meine Konsole immer "offen" - mit physischem Zugriff aufs Gerät ist alles andere eh nur ein Deckmantel).