IPS Ruleset Provider - how to add new Ruleset provider

Security Intrusion Prevention
1

Hello,
ids.cgi does use a predefined list of Ruleset Providers - after searching a bit I think all are in the /var/ipfire/suricata/ruleset-sources

Apart from manually editing that file (and maybe loosing the entry when a future core update will overwrite that file content) what are the options to add a new IPS Ruleset Provider?

Is there a “.local“ ruleset-rules file I could use? (I did not saw any include directive in the file…)

Thank you

PS: my addition to ruleset-sources:

#Peter Russell jpgpi250 DoH rules.

    prussell => {
            summary => "Peter Russell jpgpi250 DoH rules",
            website => "https://github.com/jpgpi250/piholemanual/tree/master?tab=readme-ov-file#doh",
            tr_string => "russell green doh rules",
            requires_subscription => "False",
            dl_url => "https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOH/DOH.rules",
            dl_type => "plain",
    },

That worked new ruleset was tested - look at Question about DNS over HTTPS - Networking / DNS - IPFire Community

2

Sorry, I do not recommend this!

  1. /var/ipfire/suricata/ruleset-sources is a IPFire system file. A CU can overwrite this
  2. there is no .local file. IPS rulesets are selected by the IPFire project and are checked for common open source rules: free, GPL, rights and (important!) long term availability.

This concept allows for reproducible results.

1 Like
3

Same, but for other reasons.

When a domain is blocked properly, the client should see a clear DNS result such as NXDOMAIN, REFUSED, SERVFAIL or a sinkhole address like 0.0.0.0. That tells the application “this name isn’t usable, give up and move on”.

If you instead drop traffic at the IPS level, the client often sees no response at all just timeouts. Many applications don’t handle that gracefully and you can end up with odd behaviour: long delays, repeated retries, or things that appear to “randomly” hang or crash because they’re waiting on a reply that never comes.

Thanks,
A G

1 Like
4

@ag, my post was about the adding process for rules.

For the specific rule set, you are absolutely right.
DNS handling should take place in the DNS resolver. Peter Russels advice target the pihole project.
But PiHole on an extra system in the local network isn’t as straightforward and transparent as it seems.
You must direct all DNS request to the PI running PiHole. Not trivial.
If DNS blocking happens in the internet gateway, the IPFire in your LAN, it is much more straightforward. DNS request can be redirected to IPFire’s DNS resolver. The blocking can take place with RPZ mechanism (which is used in PiHole, also).

1 Like
5

Gentlemen,

Only recently I saw the RFC that should (will?) implement DDR. And this article about making DoH discoverable https://techcommunity.microsoft.com/blog/networkingblog/making-doh-discoverable-introducing-ddr/2887289

Combined with some apps (for the moment browsers) and possible DNS client internal config to directly attempt DoH (with or without DDR) toward known servers, those two indicate a possibility in the future that some DNS traffic will simply escape the FW redirect rules and the RPZ.

It is not my intention to launch a debate, quite the opposite.

My goal is to add several layers that block DoH (and DDR) one of them being IPS rules Peter Russell provided.

Thank you for sharing your views and the fact that IPS Ruleset Provider list is not designed to be edited - I acknowledge the underlying consequences of editing it.

2 Likes
6

You are invited to discuss this addtional IPS rules in the dev list.

2 Likes
7

Yes, using this IPS list as a policy enforcer, rather than the primary method of blocking would be a good IPS addition.

Thanks,
A G

1 Like
8

This list that has been mentioned has a script that is run daily that aggregates the IP’s or URL’s for DoH sources from 23 other lists.

I checked the first 11 sources for when they were last updated.

  1. 2019
  2. 2020
  3. 2022
  4. 2018
  5. 2 days ago
  6. 2020
  7. 2024
  8. Today but this lists dnscrypt resolvers!!
  9. 2019
  10. April 2025 - from an experimental tool that allows you to test new DNS-over-HTTPS services on Android
  11. Script runs every hour but contents are manually updated approximately every month

I stopped looking further at this point.
It seems to me that no checking is done on what is aggregated. It would be hard to do on the individual entries as the list ends up with over 4000 IPS rules.

However, at the least I would expect some simple validation that the lists are still being updated.

This does not look like a good list to me and not one that I think should be added to IPFire.

2 Likes
9

If you are interested here are the sources that I added, just don’t forget to backup “ruleset -sources” file

# Abuse.ch SSLBL Blacklist rules.
sslbl_blacklist => {
	summary => "Abuse.ch SSLBL Blacklist Rules",
	website => "https://sslbl.abuse.ch/",
	tr_string => "sslbl blacklist rules",
	requires_subscription => "False",
	dl_url => "https://sslbl.abuse.ch/blacklist/sslblacklist.rules",
	dl_type => "plain",
},

# Abuse.ch URLHaus rules.
urlhaus_blacklist => {
	summary => "Abuse.ch URLHaus Rules",
	website => "https://urlhaus.abuse.ch/",
	tr_string => "urlhaus rules",
	requires_subscription => "False",
	dl_url => "https://urlhaus.abuse.ch/downloads/ids/",
	dl_type => "archive",
},

# Abuse.ch Threatfox Blacklist rules.
threatfox_blacklist => {
	summary => "Abuse.ch Threatfox IOC Rules",
	website => "https://threatfox.abuse.ch/",
	tr_string => "threatfox blacklist rules",
	requires_subscription => "False",
	dl_url => "https://threatfox.abuse.ch/downloads/threatfox_suricata.rules",
	dl_type => "plain",
},