Messages

So many businesses dissapeared swallowed by BOGUS responses. Personally I haven't seen one, and have deployments with over 1M queries daily, roughly 70% being DNSSEC validated by the local resolvers regardless of the upstream.

Trust but don't verify - it's the old security adage that keeps businesses alive.

PSA: Update your Unifi deployments - MongoDB - critical issue - patch available

https://www.bleepingcomputer.com/news/security/mongodb-warns-admins-to-patch-severe-vulnerability-immediately/

Code Select Expand

Installed packages to be UPGRADED:
        harfbuzz: 10.3.0 -> 12.2.0 [mimugmail]
        htop: 3.4.0 -> 3.4.1 [mimugmail]
        mongodb70: 7.0.24_1 -> 7.0.26 [mimugmail]
        openjdk17: 17.0.16+8.1_4 -> 17.0.17+10.1 [mimugmail]
        unifi9: 9.5.21 -> 9.5.21_1 [mimugmail]
Thanks again Michael and Happy Holidays

... I always know the specific site from which it was leaked...

Some email providers allow the use of aliases in the form of site+user@domain.com: forumOPN+mikemyers@gmail.com

...I seem to be capped at 1g (950mbs)...

Been following this thread and I'm surprised this didn't come up yet:

Did you set up traffic shaping for 1Gb way back when and forgot to adjust it for the 2Gbps plan ?

[/usr/local/share/java/unifi/data/backup]

Thanks Michael.

I didn't see your post until now, so while testing some other updates I was hit by Unifi9.5 which wasn't working at all.

At the end of it all 9.5 is running fine, so this is both a success story and a cautionary tale - since the existing 9.1 guidance didn't work in two of the most common scenarios of ending up with a broken 9.5.


To start, whether already on a broken 9.5 or planing to upgrade - take a snapshot.

Next, if still having a running Unifi9.1 download the config. Else copy /usr/local/share/java/unifi/data/backup folder and make sure the ae valid/recent .unf files in the autobackup folder.


At this point, whether on 9.5 or 9.1, running through the steps outlined in the 9.1 thread to stop and remove Unifi, remove /usr/local/share/java/unifi/data/ and install the 9.5 version will lead you to the same ~"Unifi is loading..."~ message in the browser that I waited on more than 20 minutes for a few times (on a FW4c as a reference).


From this point onward the fix is straightforward~ish. If on a broken 9.5 with a valid config file you can start here.

1)

Code Select Expand

rm -fr /usr/local/share/java/unifi
You read that right. Simply removing /usr/local/share/java/unifi/data/ won't work for 9.5

2)

Code Select Expand

pkg install -f unifi9
The removal of the unifi folder above breaks things and reinstalling the package is required.


3) From OPNsense, start Unifi. Wait for the initial Unifi setup page to show up by accessing the FW IP on port 8080 (that did a redirect for me to the usual https port where I'm running the controller).


4) With the Unifi setup page loaded, search for at the bottom of the page and import the latest backup-date.unf file you have available.

Confirm importing the config from version 9.1.x

You'll be told to wait as Unifi reboots. In my case the process either died or was stopped instead of rebooting. I went to OPNsense and started it from there.


5) Login to 9.5. Given a recent unf file (mine was 2 days old) everything will be up and running



This is my story, hope it may be useful to someone.

YMMV



Again, big thanks to Michael for updating the repo.

It's been a while and I didn't receive any PM on how to set up qfeeds. Is the beta testing over or having enough accounts already ?

........
There is an use case to consider:

If an user with the free Community license starts to see a block for a particular Destination, there is no possibility to check why is that the case as the IoC lookup is not available to them. This can cause either a significant amount of tickets on your end or on the OPNsense forum end.
Would you maybe consider to allow IoC lookup as well for Community license but maybe limit it to 5 lookups per day?

With the IoC you're walking a very thin line. If tracking a new emerging threat you don't want to tip your hand. Otherwise if the information is public there's no reason to withhold that information.

Checking the IP history would probably most helpful here, and inspecting the traffic seeing if dealing with a formerly bad IP that may have been reused for legitimate purposes.

Hi Stefan,

Here are my initial thoughts from last week when the thread was new - I just didn't get to post it:

Hi Stefan,

The FW rule guidance in your manual is incorrect on a few counts and needs to be corrected:

1) The WAN interface will default deny any incoming connection. Unless providing external services and wanting to make sure the malicious IPs will not connect to your service - there's no real need to deny traffic source Q-Feeds.

2) The (v)LAN interface can never be the Source IP for the malware traffic blocked by q-feeds - unless you're actually hosting those networks behind OPNsense.

For the (v)LAN traffic the goal is to Reject (not drop) all traffic Destination q-feeds malware IPs. Another thing to note is that when applying the same rule to multiple interfaces you'll want to create a Floating Rule instead.


I'm interested to see how/if there's gonna be an overlap between packages needed to install q-feeds and packages provided by other repos, such as mimugmail. And since CE has a cadence of 2-3 weeks for a dot release the speed of fixing/adjusting q-feeds to the changes in core will be something to watch.

On a second read, there's a disconnect between the text and visual representation of the rule. The text is slightly better but for a I'm afraid many will default to reproducing the rule as visually depicted in the manual.


After reading the thread a few more ideas come to mind:

For the payed tiers - the 4h and 20 minutes update intervals may sound great on paper. In practice however with the added complexity a few things are bound to happen:

a) Low powered systems will be busy downloading parsing the new ip lists far too often and for a long time each time.

b) Especially on initial deployments where an alias dealing with false positives doesn't exist yet it may be disruptive for the enterprise and painful for the network admins having the playing field suddenly changing every so many hours or minutes.

I think it would be far better if the payed tiers would allow an arbitrary interval to be set, where the lower limit is what the plan allows. "Once a day" may prove to be a very popular choice regardless of the chosen plan.


These are just a few initial thoughts, I may be able to comment more once I get to test the plugin.


For anyone trying the plugin - don't forget to take a snapshot first. Murphy's always watching ;-)

New BIOS versions published for the following FWs:


DEC700 and DEC2700 series -- 08-2025 Version 34

Code Select Expand

BIOS Information
        Vendor: INSYDE Corp.
        Version: 05.39.21.0028-A10.34
        Release Date: 03/21/2025


DEC800 and DEC3800 & DEC4000 series -- 08-2025 Version 17

DEC4200 series -- 08-2025 Version 26 -- Already announced by AdSchellevis in Announcements



BIOS download page

The appropriate way would have been to change the Type from Development to Community in System -Firmware -Settings


What you did was destructive and risky - and uncalled for. But it was golden guidance from AI.

No should be all good this time. In case of an issue booting the older kernel will get you back to 25.4.

Snapshots are also an option but may be overkill for this particular issue.

A test kernel has been provided on Github by Stephan

Code Select Expand

opnsense-update -zkr 25.1.6-axgbe

With FreeBSD 14.3beta2 out, if this gets an actual fix I'd be surprised if it makes it prior to 14.4 upstream.

( With OPNsense that would most likely be included in the next dot release that has a kernel update and at least one test kernel before that )

Firewall - Diagnostics - Aliases

Click on Update Bogons, wait ~10-15 minutes then reboot

Actually there's an easier way to do it where two FWs are present. Requires a USB cable connected from one to the console of the other.

First you'd ssh into the controlling FW, drop to a shell, and use this command to open the serial line to the other:

Code Select Expand

cu -s 115200 -l /dev/cuaU0