Hello Adolf and all, thanks for joining the discussion and sharing your thoughts here. > Hi Stephan and all, > > Sorry for late response but I am very busy with lots of other things > at the moment and time just ran away from me.
The end of the year is very near, I'm struggling with very similar issues at the moment. > > On 03/12/2025 21:02, Stefan Schantl wrote: > > Dear list followers, > > > > as promised in the IPFire community portal and as the subject of > > this > > mail already suggested, I want to start the discussion about where > > a > > possible "filtering" mechanism could be implemented. > > > > The main goal of this process should be to collect various > > locations > > where such a feature could be hooked in, determine their pro and > > cons > > and hopefully find the best solution for our needs. > > > > Please keep in mind that at this early stage we mainly should focus > > on > > technical aspects and the "where" instead of deeper details about a > > possible implementation - the so called "how". > > > > At the moment I am aware of four possible locations, but please > > feel > > free to suggest new ideas in case I missed one. > > > > These are: > > > > * Web proxy (Squid) > > * Firewall engine (IPtables) > > * IDS/IPS (Suricata) > > * DNS (unbound) > > Does the discussion really need to go back to the point of discussing > which of these approaches is the best one for filtering. It seems to > me that if that is the case an expectation would be that one of these > approaches would be chosen as the best one and the rest no longer > used but I don't think that is a reasonable conclusion. At this point I don't expect or prefer any solution. The idea was to do some brainstorming about the different possible solutions, where and how the could work. During this task we may came to the conclusion, that none of them fits our requirements, may we need multiple of them at the same time or there is the one which fits everything and therefore we can drop old code... Doing the basics before may also helps to detect possible limitations and pitfalls during later development and coding. Additional I see the discussion as some kind of archive, which easily can be accessed at a later time in case we need some help to remember why one or certain decisions have been made in the past. > > Each has pros and coependent on the particular use case, although all > also have some overlap and also some overlap with the IP Blocklist > approach that is also available in IPFire, although that probably > counts as covered by iptables. > > It seems to me that we have the Web Proxy, the Firewall Engine and > the IDS/IPS systems in place as filtering methods. We currently don't > have the DNS approach in place as a filtering method. A big issue > with the DNS approach is to do with concerns over the list(s) to be > used for that approach and it seems to me that this is the area that > needs further discussion around the sources, their > origination/licenses and how to ensure the minimisation of resources > to only download what has actually been changed and which lists make > sense to include. The issue with lists - which ones, their licenses etc - of course is an other very important topic and also needs a lot of attention. To keep things a bit easier at the moment, I would suggest to do the technical part first and based on the gained knowledge we can go further with the sources part. Best regards, -Stefan > > Regards, > > Adolf. > > > > > > I'll start with my thoughts about placing that feature in the > > firewall > > engine. Feel free to add additional comments or likewise do the > > same > > task for any other location. > > > > -- Firewall -- > > > > Positive: > > > > * Located in the Linux kernel, no extra daemon during runtime > > required > > > > * Seamless network integration, no configuration on the clients > > required > > > > * Bypass not possible, because traffic to the target address is > > blocked > > > > * ? > > > > Negative: > > > > * Possibly huge amount of single rules in one or more chains, which > > needs to be passed and may produces overhead and therefore could > > slow > > down network traffic (This could be reduced by combining IPtables > > and > > IPSet's) > > > > * IPtables is based on IP addresses, so hostnames will be resolved > > the > > first time a rule with hostnames as argument will be created. This > > will > > lead to incorrect rules in case the address of a former loaded rule > > changes later. (A very theoretical workaround could be to > > periodically > > reload/recreate the rules) > > > > * If multiple services are hosted on the same address, none of them > > can > > be accessed because the traffic to the entire host is blocked > > > > * ? > > > > I hope this first example shows you how this concept of > > brainstorming > > and discussion could be done. I'd like to thank anybody in advance > > who > > is willing to join and share his opinions here. > > > > Best regards, > > > > -Stefan > > >
