I just read the new blog post on this. First, thank you! Second, this could be a game-changer for IPFire. I’m very excited about this and I think many current users will be as well as new users who will want to try it out. Third, developing it to be cross-platform and usable in many other scenarios besides IPFire is selfless and generous.
Seriously, I hope this is the first step in a major uptick in donations, development and userbase.
Thank you again, IPFire Team.
Thank you very much for your kind words.
I feel very excited about this, and we are just starting. So hopefully a lot of people will back our efforts and give us the funding that will allow to take this really far.
To the moon!
Hi Michael,
I couldn’t find any information about the basis of this list. Where do these domains come from?
Will there be an API through which “trusted partners” can report relevant domains, perhaps even automatically? Similar to how abuseipdb does it? And how quickly will reported domains be blocked? I run a relatively large mail server, and new phishing domains appear almost hourly. Ideally, these domains would be reported quickly and then blocked on the local network. The faster, the better. I think it’s extremely important these days to react very quickly to new threats.
First and foremost, I would like to sincerely thank you for your work so far. If desired, I would be happy to contribute data to this list in the future.
If you go to the individual pages for each categories it lists the sources used for that category.
Here is the link for advertising. If you go down that page ot will show the sources for the advertising list.
https://www.ipfire.org/dbl/lists/ads
There is also a report button at the top of the dbl page and if you click that then the following page is shown where you can report any issues.
Hello @Steven,
There is an API, but at this time it is read-only: IPFire DBL API - Swagger UI
I don’t think that we are generally looking to have a lot of automatic reports, because how would we simply get through them? I would be happy to take the discussion further and see what reliable data sources we can obtain to improve the lists.
Domains will be blocked after a moderator has accepted or rejected your report. This is manual process and therefore not instantaneous but still super fast.
How do you identify what is a phishing domain?
FYI, the adblock package in OpenWrt now supports the new IPFire DBL with all 12 categories as well. Many thanks for the new comprehensive feed! 
For reference: adblock-4.5.1-3
Oh nice!
Thank you very much @dibdot for making this happen. I hope that we will get it integrated into many more things.
I have been working on suricata-update this week:
Where else do we have to integrate IPFire DBL so it is only one click to turn it on?
@dibdot, can you give me some instructions how to turn this on in OpenWRT, so we can add it to the How to Use? page?
Maybe something like that:
Using IPFire DBL with OpenWrt Adblock
OpenWrt users can enable IPFire DBL directly through the Adblock package by adding it as an external blocklist feed. In LuCI, navigate to Services → Adblock → Feed Selection, activate the ipfire_dbl feed and select the necessary IPFire categories. Finally hit Save & Reload to trigger an Adblock reload so the list is downloaded and included in the active blocklist. Once enabled, IPFire DBL will automatically update according to your Adblock refresh schedule, providing an additional layer of domain‑based threat protection.
Nice!
I have added it to the page right here: www.ipfire.org - IPFire DBL - How To Use?
And I added the OpenWrt logo to the index page, too.
Hi,
thanks for creating IPFIRE DBL!
Is there another way to submit urls than the web form at https://www.ipfire.org/dbl/report ? Maybe some API?
What information is preferred to verify a submission for the PHISHING DBL as fast as possible?
Hello Andreas,
we do have an API, but that is currently not ready for submissions. Simply because we have not reached that stage, yet.
This is of course a very interesting question. Having a human in the chain would make any list updates significantly slower, but on the other hand we would open the door to bad submissions if we didn’t have some checks in the chain.
Happy to hear ideas on what data you have to offer that would be useful.
Hi Michael,
I’d like to jump in on the discussion.
I addressed this issue in a completely different sector; to be honest, it wasn’t even related to the IT sector.
But I think the method used that time could streamline the verification process here.
In my case, we had trusted users, and what they posted wasn’t verified by a third party.
To remain a trusted user, you had to update your status every 12 months; if you didn’t, you automatically lost your status.
It’s an idea worth considering, as are many others. In my case, it works and is still working.
I don’t think that will work well. When using blacklists, time is a crucial factor. I understand the concerns about trustworthiness, acceptance, and reliability that this project aims for. However, speed and timeliness are even more important. A moderated system can never achieve that, especially not in the age of AI. No matter how large a team is, it will always sleep, eat, work, take vacations, get sick, or enjoy life.
Believe me, I know what phishing URLs are. I’ve been running mail servers for over 20 years, fighting spam, viruses, and phishing. That’s precisely why I know that time is an extremely critical factor, especially when the database is to be used as an RBL/DNSBL.
For example, my mail servers have been hit by several new phishing attacks in recent days, targeting the German companies DKB and mobile.de. These attacks were previously unknown.
In any case, it was just an idea and a suggestion for this project. If you don’t want to do it that way, that’s fine too. Personally, I’m not going to manually visit a website and fill out a form to report something when all my other blocklists and services with APIs are working perfectly.
Hello Steven,
It does work really well. That is the whole point here. There will be a moderator be looking at a report and therefore there is some quality assurance.
What you mean is that it won’t scale. Nobody is doubting that at all.
But we are currently in a startup phase of this project and having everything ready from day one with zero funding is something we simply cannot do.
I don’t know where you are getting that from. It is also fine with me if you prefer to not take part in improving IPFire DBL. I was just hoping that you would have a workable proposal for me instead of suggesting that we would accept anything that anonymous people are throwing against the lists. It won’t take long until we then shift our entire attention to only fight false-positives. So we will have to have some steps in there that ensure that we create the best list that we can possibly provide. I think that this is a very reasonable goal.
What other lists are you using and how are you submitting new data using their APIs?
To improve the reaction time for inviduals, it is possible to implement white lists. Means DBL is curated on a general basis, only verified cases find their way into the list. Systems using DBL allow a list of ‘trusted’ entries which is checked before the DBL list.
@jon has introduced such a mechanism in his proposal for RPZ lists. There is a special ‘allow RPZ’ which is applied first. A ‘block RPZ’ is installed,too, and applied last. This allows blocking of specific URLs, for example blocking requests not yet included in the common lists.
No offense, but it would be nice if you didn’t always react so bitchy. It’s really no wonder that no real IPfire community has developed to support this project with relevant things. I never said anywhere that anonymous reports should be accepted. Quite the contrary. I spoke of “trusted partners.” Perhaps you should reread my original post and try to understand it.
What other services can do this via an API? Spamhaus, Blocklist, Crowdsec, Abuseipdb (even part of Fail2ban), etc.
However, I could have made my list of phishing URLs available for download, which you could have added as a source. But you didn’t even think to ask for it. Instead, you focus on “problems” again. You ask how to identify a phishing URL as if we were all little children who don’t know what we’re talking about. I’m sorry, but that shouldn’t be the basis for how you talk to people who want to support the project.
I’m out. I don’t feel like discussing this either. For me, these are all basics. If you don’t want to do it, you don’t have to. There are other projects that appreciate any support (not just money). All good.
What is the difference between a web site and an API in the field of DBL maintenance?
An API ( application programming interface ) in this context can only change the server side database ( of suggestions ) and is just a web service. A web site for input of change requests is the same, but you must not program an extra application.
About phishing URLs @ms requested to send that a list to the community ( or devs ), only. What is wrong with this?
A system like IPFire gives a hardened secure device. On your instance you can do anything to drill holes into this wall. But these holes should not go to the base product. To avoid this, it is necessary to do human inspection!
I am happy to read this. You clearly don’t seem to be interested in something constructive here.
We don’t intend to create yet another copy of existing lists. There would be no benefit in that. The intention with IPFire DBL is to create something new.