Looking for testers Q-Feeds plugin

[Patrick M. Hausen]

I'll send you a DM with as much entries as the Live View allows.

Anyway I thought including FireHOL and Spamhaus by default would be a no-brainer. Reputable open sources.

Kind regards,
Patrick

[Q-Feeds]

I'll send you a DM with as much entries as the Live View allows.

Anyway I thought including FireHOL and Spamhaus by default would be a no-brainer. Reputable open sources.

Kind regards,
Patrick

Thanks a lot! Please give us a few days to have a look at it. Well the interesting part is that we do monitor those lists, but we process feeds, not just copy and paste everything in our feed. FYI we monitor over 70 million IOCs in our backend (and counting).

[passeri]

Security: Q-Feeds Connect: Events shows every event twice. Also, the interface column is empty.

(Sorry if this is a known issue, just started testing Q-Feeds and didn't read all 200+ comments.)

You cannot view this attachment.

I am seeing the same, no interface and every event twice.

More information will be needed. Mine operates normally, populating the interface and without duplication.

I use a DEC697 and have no extras beyond Q-Feeds Plus and Crowdsec free.

[Maurice]

Pretty basic setup.

The firewall rules are:
block drop in log quick on vtnet0 inet from <__qfeeds_malware_ip:667695> to any
block drop in log quick on vtnet0 inet6 from <__qfeeds_malware_ip:667695> to any

Events are only duplicated in Security: Q-Feeds Connect: Events. They show up correctly (only once) in Firewall: Log Files: Plain View.

vtnet0 is the WAN interface:

You cannot view this attachment.

[gtwop]

Firewall: Rules: Floating

On Rule 1: Interface (LAN) only no other.

On Rule 2: Interface (WAN) only no other.

Had the same problem, in my case I had (LAN WG0) and (WAN WG0) removed (WG0) on both
now I get all single entries.

Note: After you make the change Events will lose all its entries, it takes around
5-10 minutes before new entries re-appear one at a time.

I also have TCP/IP Version: (IPv4) only as choice.

[passeri]

I experimented with Threat Lookup using the first couple of entries in the Events list, i.e. the most recent. One of those IPs, 118.38.108.242, returned no results?

Does that mean it is not on or no longer on any threat list or it is but nobody knows why it is there?

[Q-Feeds]

I experimented with Threat Lookup using the first couple of entries in the Events list, i.e. the most recent. One of those IPs, 118.38.108.242, returned no results?

Does that mean it is not on or no longer on any threat list or it is but nobody knows why it is there?

That is interesting! That IP is not in our database (anymore).

[Kets_One]

That would be a list of more than 2,300 sources and it's still growing. It's not purely OSINT, and it also includes our own proprietary sources, such as data from our honeypots. The real value is in the work we've already done, filtering out false positives and prioritizing the data. Simply adding raw OSINT feeds often leads to tons of false positives and unnecessary IOCs clogging your memory.

I used to block via freely available lists and now that I activated your plugin I put that "block based on free lists" rule after the Q-Feeds one.

Result: for 100 blocked connections 72 are caught by Q-Feeds and still 28 by the free lists.

My free lists are:

FireHOL1
FireHOL2
FireHOL3
Spamhaus DROP
Spamhaus DROP6
Herr Bischoff's IP blocklist (https://ipbl.herrbischoff.com/list.txt)

Surprised at least FireHOL and Spamhaus are apparently not included in your feed?

Kind regards,
Patrick

P.S. I can send you a list of addresses if you want to investigate. And of course these numbers vary a bit over time, but roughly 25-30% make it past your feeed and are caught by my other block lists.

I also noticed the same thing. Can assist if needed.

[troplin]

Anyway I thought including FireHOL and Spamhaus by default would be a no-brainer. Reputable open sources.

When I was setting up my blocklists some time ago I was curious which FireHOL level to use and did some digging.

I noticed that quite a few source lists in there are stale. Some have changed the URL or format or are not (publicly) available anymore.

Since FireHOL keeps the last available copy of all sources in its own repo, that means (for better or worse) that it probably contains a lot of IPs that at some point were part of a source blocklist but aren't anymore.

[Patrick M. Hausen]

I use these:

Code Select Expand

https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset
https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level2.netset
https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level3.netset
https://www.spamhaus.org/drop/drop_v4.json
https://www.spamhaus.org/drop/drop_v6.json
https://ipbl.herrbischoff.com/list.txt

All actively maintained and current, it seems.

[Q-Feeds]

We've checked the logs you've send over and here are our first findings:

• High false positive risk IOCs: Some of the addresses weren't included in our feed because they score high on false-positive risk. For example, GitHub IPs, Google bots, and other cloud infrastructure. While blocking these could work in some setups, it could disrupt others. We intentionally exclude them to reduce potential support pressure and avoid accidental outages. This ensures our feed is reliable for a wide range of users rather than only aggressive environments.
• FireHOL lists: FireHOL contains very large subnets, which can cause a lot of false positives. They themselves recommend using their lists for enrichment rather than direct blocking if I'm not mistaken.. Blocking whole /16 or /8 subnets is extremely risky for production networks, which is why our feed focuses on more precise, actionable IOCs. It does create a lot of hits though ;-)
• Warning for those unfamiliar: FireHOL 1 also contains RFC1918 private addresses never use it outside of WAN interfaces unless you know what you're doing.
• Older known IOCs: Some addresses were excluded because they've been known for a long time and are often already mitigated by other protections. We've adjusted our algorithms to stretch coverage safely where it makes sense, but the goal is always to maximize real threat protection without introducing unnecessary noise.
• Focus on real threats: The "missing" addresses are mostly potentially unwanted traffic but not truly dangerous. Our feed prioritizes high-confidence threats as much as possible, so users aren't blocked by mass "noise" like search engine bots, proxies, or reused cloud IPs. Benchmarking purely by count can be misleading, blocking one actual APT attack is worth far more than tens of thousands of minor unwanted connections for us.
• Complementary lists: There's no "one list to rule them all." Q-Feeds is optimized for precision, but free lists like FireHOL or Spamhaus DROP can still be valuable for enrichment or as an extra layer for some situations and users. Using them together is a solid strategy.

That said, your feedback is very useful, and we can continue looking at those edge cases to improve coverage where it makes sense.
Thanks again for your detailed testing really helps us improve!

[Maurice]

Turns out the Interface column in Security: Q-Feeds Connect: Events only shows the interface's (optional) description, not its identifier (lan / wan / opt[n]). If there is no description, the column remains empty.

This could be improved - show both or show the identifier if the interface doesn't have a description.

[Patrick M. Hausen]

We've checked the logs you've send over and here are our first findings:

• High false positive risk IOCs: Some of the addresses weren't included in our feed because they score high on false-positive risk. For example, GitHub IPs, Google bots, and other cloud infrastructure. While blocking these could work in some setups, it could disrupt others. We intentionally exclude them to reduce potential support pressure and avoid accidental outages. This ensures our feed is reliable for a wide range of users rather than only aggressive environments.
• FireHOL lists: FireHOL contains very large subnets, which can cause a lot of false positives. They themselves recommend using their lists for enrichment rather than direct blocking if I'm not mistaken.. Blocking whole /16 or /8 subnets is extremely risky for production networks, which is why our feed focuses on more precise, actionable IOCs. It does create a lot of hits though ;-)
• Warning for those unfamiliar: FireHOL 1 also contains RFC1918 private addresses never use it outside of WAN interfaces unless you know what you're doing.

Understood. I only block inbound connections on WAN via IP lists, not outbound connections. The latter I leave to DNS based blocking via AGH.

So no harm done, au contraire, rather, when cloud addresses and bots cannot access e.g. my Nextcloud.

Thanks for the quick and thorough analysis. I'll switch the order of rules around to see what percentage your service catches that FireHOL and Spamhaus don't. I'll report back.

Kind regards,
Patrick

[Q-Feeds]

Turns out the Interface column in Security: Q-Feeds Connect: Events only shows the interface's (optional) description, not its identifier (lan / wan / opt[n]). If there is no description, the column remains empty.

This could be improved - show both or show the identifier if the interface doesn't have a description.

Thanks for catching this!

[Patrick M. Hausen]

Security: Q-Feeds Connect: Events

Where exactly is that, please? OPNsense or TIP? Could not find it.