Looking for testers Q-Feeds plugin

[Q-Feeds]

Same same ... some threat report, i.e. which IP addresses were blocked and why, is definitely called for to make this a product. Check out crowdsec for reference. I only dropped crowdsec because the free block lists are a joke and paid subscription starts at something around 90$ per month which is a no brainer for a company, but definitely too much for a home lab.

I just jumped in and spent the 100 for the plus license to get this project going. I hope they deliver :-)

Thank you, Patrick!
We really appreciate your support and don't worry, we won't let you down! :)

[cookiemonster]

I'm interested in giving it a go if there's space for another tester.
I'm currently using Zenarmor on a trunk with two VLANs, and Crowdsec for my internet-facing haproxy, and it has been working quite well.

[Q-Feeds]

I'm interested in giving it a go if there's space for another tester.
I'm currently using Zenarmor on a trunk with two VLANs, and Crowdsec for my internet-facing haproxy, and it has been working quite well.

The more, the merrier! :) Details are in your inbox.

[cookiemonster]

I'm interested in giving it a go if there's space for another tester.
I'm currently using Zenarmor on a trunk with two VLANs, and Crowdsec for my internet-facing haproxy, and it has been working quite well.

The more, the merrier! :) Details are in your inbox.

Got them. Thanks !

[Q-Feeds]

This is just a brief very short initial sump-up, I don't have (yet) access to the other features in TIP,


The Good:
1. easy to install
2. easy to deploy
3. easy to manage
4. Huge list of OSINT based entries (actually this surprised me)

.................

Wow thanks so much for the great list of feedback! Here's our response:

Documentation:
Noted! We agree and will update this soon.

Q-Feeds Plugin:
Auto deployment is listed on the wishlist
Whitelisting as well
Feed choice as well

Widget:
Totally agree as wel, will be updated with better stats as well.


Miscs:
False positive reporting is now done with the support feature in the TIP but I agree we could improve this. Noted!

TIP:
Regarding the strange logs: Unfortunately wasn't able to reproduce this but very keen if other users had this same experience?


The requested:
1. Noted!
2. That could be a great way to implement whitelisting, thanks! We will discuss this with the developers at Deciso as well.
3. I'm afraid this one is for the long term. main reason is maintainability since we do support other firewalls, SIEM, SOAR, EDR/XDR etc. platforms as well. But while we grow we can do more ;)
4. Noted, again will discuss this with Deciso as well.
5. Agree! We will also implement a function which provides an option to limit the number of IOCs for devices with less memory.

Widget:
1. Yes!


Miscs:
1. Noted, will improve this on a short notice!
2. Great feature request, and totally agree as well! You're filling our backlog :)
3. We don't have a public roadmap (yet) but I'm sure that we will implement most of the suggestions in this topic. At the moment for OPNsense and our product we're in a very early beta phase, we'll keep you posted ;)
4. That's already the case.

Thank you very much for your long list! I've added it to our (already long) feedback list and we will keep you posted.

Kind regards,

David

[Q-Feeds]

Same same ... some threat report, i.e. which IP addresses were blocked and why, is definitely called for to make this a product. Check out crowdsec for reference. I only dropped crowdsec because the free block lists are a joke and paid subscription starts at something around 90$ per month which is a no brainer for a company, but definitely too much for a home lab.

I just jumped in and spent the 100 for the plus license to get this project going. I hope they deliver :-)

First of all thanks for your support!

With the plus license you can use the Threat Lookup function to check your hits. We don't collect the hits on your firewall though so currently you should copy the IOC from the logs into Threat Lookup to gather more context about why an IP is in our TI. We've added an integration to the wishlist within the plugin but it won't be on the short list for now.

Kind regards,

David

[Seimus]

Thank you very much for your long list! I've added it to our (already long) feedback list and we will keep you posted.

Kind regards,

David

Same here, thank you for replying to each individual question/point, feels refreshing. These days to get straight answers from vendors is painful (anyone who was experience with enterprise based TAC cases knows the feeling).

With the plus license you can use the Threat Lookup function to check your hits. We don't collect the hits on your firewall though so currently you should copy the IOC from the logs into Threat Lookup to gather more context about why an IP is in our TI. We've added an integration to the wishlist within the plugin but it won't be on the short list for now.

Kind regards,

David

While this is awesome that you don't collect any information about what was hit (I feel this is a strong selling point as well), keep in mind that the Community License doesn't have this feature allowed. And I see here a problem and a possible flood of user tickets forum or portal.

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?

Regards,
S.

[passeri]

Or N/week, given the Community licence works on a weekly update cycle.

[newsense]

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 ;-)

[newsense]

........
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.

[Q-Feeds]

Would you maybe consider to allow IoC lookup as well for Community license but maybe limit it to 5 lookups per day?

Or N/week, given the Community licence works on a weekly update cycle.

With the Community edition, there's no support included, so IoC context requests submitted via a ticket might not receive a response. Besides 'no support' we will improve the false positive reporting as stated before. That said it's an interesting idea though, and I've added it to our feedback list. I don't expect we'll implement this anytime soon, but it's definitely noted.

Stefan

[Patrick M. Hausen]

So the system seems to work. See screen shot.

Now, where can I find for each of these 403 blocks:

- source IP address
- reason it was blocked
- local service it tried to access
- country of origin
- source AS

?

[Q-Feeds]

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.

........

Hi Newsense,

First of all thanks for testing and thanks a lot for your feedback!

Regarding the 'WAN interface default deny' you're absolutely right! If you don't have any external services it might still be interesting to see which hits you have on our intelligence, besides that there's no real need. And the LAN interface Source is noted as well, we will update the documentation today.

On a broader note, unfortunately there's no 'one rule to rule them all' meaning every setup differs and everyone has different needs. We might want to make it more clear in the documentation that it's just an example.

For the development of the plugin we work closely together with Deciso themselves who actually already made some small changes in previous releases to the core in order to make the Q-Feeds plugin work. In the end when we release the plugin (GA) it will be part of the 'core' plugins maintained by Deciso. The next step (few weeks) will be that we're listed under the community plugins for and open beta purpose. If a hotfix would be needed we're able to, thanks to the partnership between Q-Feeds and Deciso.

Regarding the update interval; did you see any (major) performance hit while pulling in the threat intelligence? I haven't been able to reproduce while my dev-opnsense box is very limited in resources. (fair enough, there's not much traffic being processed)

Regarding the false positives: we're planning to improve both how they can be submitted and how they're handled directly on the OPNsense box. While false positives can always occur, suggesting they might impact the network every hour or even every few minutes feels a bit exaggerated. Incidents can definitely happen, but if they were happening that often, we wouldn't deserve to exist. In fact we've been running our threat intelligence across multiple platforms with multiple B2B customers for the past 13 months already, and in all that time we've only had two confirmed false positives.

That said I definitely do understand what you mean and I've added your suggestion to make it more flexible to the wishlist. Something else we're going to add is a possibility to limit the number of IOCs being pulled in for memory-bound devices while keeping the priority (risk-score) of the IOC in mind.

Thanks again for your valuable feedback!

Kind regards,

David

[Kets_One]

Hi David/Stefan,

Please find a few additional comments/questions on the plugin below.
1. How is the update process of the IoC list handled? Does it handle its own updates? How does the plugin know how often it can request updates?
Or are updates managed through the regular cron job for update of aliases under the System->Settings->cron? If so, how does the run frequency of that job relate to the update frequency enforced by the License?
2. I tried to lookup a few IoC IP-addresses via Threat Lookup and some lookups were successful, but for others I got an error or were not found.

[Q-Feeds]

So the system seems to work. See screen shot.

Now, where can I find for each of these 403 blocks:

- source IP address
- reason it was blocked
- local service it tried to access
- country of origin
- source AS

?

Well the easiest method is to use the live view with a template. Downside is that it's live; and doesn't show history.

Another way is to get the Rule ID via Firewall -> Diagnostics -> Statistics and look for the 32 character ID. With this ID you can search in you Plain View logs (Firewall -> Log Files -> Plain View) and see all the hits. Obviously this only works if you've enabled logging on the FW rule. Since you have a Plus license (Thanks!) IOC enrichment can be found using Threat Lookup on our TIP by copying the IOC. 

There are also a lot of possibilities to use external reporting, logging tools but that's another topic.

I do understand this is not very convenient and will add it to the list to further improve. For now it's a bit bound to how OPNsense handles the logging.

Kind regards,

David