Messages

Recently, I had a problem when some of my friends told me that out voice chat was choppy. When I investigated, I found my OpnSense at 100% CPU. That turned out to be due to 7 WAN block rules for various blocklists and an ongoing DDOS attack.

I had logging enabled for those rules and the log was constantly being written to. I could not even reliably use the web UI.

This made me think about how to rate-limit the logs. Apparently, with 26.7.2, there is now max-pkg-rate from pf available.
So, now, you can create two block rules, one with logging enabled, quick block and "Max packet rate [packets]" = 1 and "Max packet rate [seconds]" = 1 to have a rule that matches at most once per second and logs and another quick block rule without logging and without rate limits immediately following that.

By using that, you still have (rate-limited) logging, but without the risk for a totally overwhelmed OpnSense.

Alas, you need two rules, because the first one will not match any more when the rate limit has been exceeded. Would there be a better way of having such a thing (i.e. eat the cake and still have it)?

P.S.: Allowing rate-limiting on block rules is a potential security hole, IMHO: When you use that without thinking, the block will not be applied when the rate is too high, i.e. block rules can be circumvented by just hitting more frequently at the target....
I guess the original idea was to do this for pass rules only and rate-limiting those on the side.

I believe that, in some respects, they have come very far, but I think we are talking about two different things. I certainly expect an AI to outperform me at individual tasks — otherwise it would not be much of a tool. What I do not expect it to do is decide what my goals should be or which goals are worth pursuing.

Asking clarifying questions, decomposing a problem or comparing solution strategies neither requires nor indicates that kind of agency. Those are extremely useful capabilities, but they still operate within a goal and context supplied by somebody else.

I tend to regard current AIs as collections of remarkably powerful, but uneven, cognitive capabilities rather than thinking entities pursuing goals of their own. If they ever became better than us not merely at solving problems, but at deciding which problems ought to be solved and why, then we would indeed have a rather different problem.

I also do like the "OPNsense Science Fiction and Philosophy" wording, and maybe robotics really is further behind than "thinking", so that might be an alternative. There are still everyday tasks that even the most advanced robots struggle to perform reliably, while a six-year-old does them without thinking — such as picking up a key, orienting it correctly and opening an unfamiliar lock.

That is an interesting and difficult question - I am grateful I do not have to ponder that out of sheer necessity.

What I see now is that LLMs have some specific advantages over humans. For example, the more capable models can keep a much larger amount of information in their working context at once - something I have found much less useful with smaller local or free models.. They can therefore do tasks "in memory" for which I would need pencil and paper, or several intermediate steps. They can also access information on the Internet much faster than I can.

So I basically use them as tools that can be guided and directed by me - and much more efficiently and cheaply than a team of human assistants ever could.

For people doing intellectual work, I would argue that the important thing is to develop the skills needed to make the best use of these tools. That being said, it still takes a lot of expertise and problem-solving ability to direct them properly - at this point, they still need expert guidance and supervision.
My best guess would be that the gap between good and bad engineers will probably widen. There may be fewer people doing this kind of work, but those who remain in demand will be highly skilled and very productive.

So I would invest less in learning one particular new technology, and more in strengthening problem-solving skills: learning how to frame a problem, break it down, question assumptions, move between different levels of abstraction and determine which problem actually needs to be solved. Domain expertise certainly helps, but these skills transfer remarkably well between domains.

Quite often, the important question is not how to perform a task correctly, but whether it is the right task to perform in the first place. Those decisions should not be left to managers alone, and AI is certainly not suited to making them either.

That is something I have been practising for decades. Story of my life. Even without the AI part.

Nice find, but:

a. More interesting than the "no match: Go" line is the line immediately before it:

Remote protocol version 2.0, remote software version Go

So there really seems to be an SSH server responding — just apparently not OpenSSH. The presented server string seems to be "SSH-2.0-Go".

b. The odd part about that is that the server presents a known host key:

Host '192.168.11.1' is known and matches the RSA host key.

That can simply mean the user accepted that key on an earlier connection, however that host key was exactly the one that was stored for 192.168.11.1. So it would be useful to check whether this fingerprint actually matches the SSH host key of the OPNsense box.

c. I would compare both the banner and the host key directly:

Code Select Expand

# on OPNsense
nc 127.0.0.1 22
ssh-keygen -lf /conf/sshd/ssh_host_rsa_key.pub

# from the affected client
nc 192.168.11.1 22
ssh-keyscan -t rsa 192.168.11.1 | ssh-keygen -lf -

If localhost says OpenSSH... while the client gets SSH-2.0-Go, then something in the network path — e.g. NAT/redirect/proxying — is clearly intercepting the connection. The interesting question is: who answers here? I doubt that it is OpenSSH on OpnSense, so the version change does not matter.

Einfach mal die Suche nutzen, wie hier unter Punkt 16 beschrieben?

https://forum.opnsense.org/index.php?topic=21839

Oder sogar in der offiziellen Dokumentation:

https://docs.opnsense.org/manual/how-tos/pppoe_isp_setup.html

Ob das WAN-Interface auf einem VLAN aufsetzt, also die OpnSense selbst taggt oder nicht (also der Fraytek taggt) ändert nichts: WAN ist immer PPPoE bei einem solchen Setup.

From one retiree to another: On a side note, just because that is probably not too obvious for everybody (I learned this just now): Try the paid versions of any cloud LLM - they are order of magnitude better that just the free crap.

I found over the course of the last two years that the free stuff did not get better, but even seemed to get worse. This may have been the result of the companies trying to reduce non-paid efforts. I found that answers came too early and were imprecise to a level that they caused more harm than good. Switching to a paid version and selecting a better model immediately changed the game. In their current shape, cloud LLMs can really help speed up things. I could do most of that stuff myself, but it would take me much longer.

Could be depending on the type of key or SSH client used, especially if the key and/or client is very old and/or defective (there were compromised / blacklisted keys because of a bad RNG). The defaults for key security are ever increased with newer OpenSSH releases. That is, bad or insecure mechanisms are slowly being thrown out.

Try to create new SSH keys with a modern client, install the public key and try if that works.

Did you put the actual string "Hourly config backup to Git/Forgejo" into the cron job parameter for "remote backup" instead of a random delay?

Patrick is right. Don't bother with USB adapters on OpnSense, use APs.

As for the router idea: I think you are mixing up concepts here. If the router really acts as a router and does NAT, OpnSense will not be able to discern between devices behind that router, so no. If it can be repurposed as a switch, then in a sense, yes. However, all devices connected to the switch can interact without OpnSense even interfering.

Also, what you can do is limited once the devices have internet access, because traffic might happen on different ports and encrypted while you cannot see what's in it. Complete control is a myth - unless you block everything.

Rules per device is possible, but then again: how do you even identify a specific device? By IP? By MAC? Good luck with either.

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.