From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim FitzGeorge To: development@lists.ipfire.org Subject: Re: ipblocklist - Call for testers (disable attribute in sources) Date: Mon, 11 Apr 2022 22:51:04 +0100 Message-ID: <0b92652d-9c2f-d690-ccfd-865e38650f32@tfitzgeorge.me.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8657045111361712074==" List-Id: --===============8657045111361712074== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I've not had a chance to look at the code in detail, but a few comments: - The disable value in the sources file is intended to disable conflicting se= ts when necessary. It's partly in reaction to people who just enable everything without thinking about it, but = it's also because for the blocklists it's relatively easy to identify which lists are subsets of others. A good e= xample is the three Feodo lists which are are different versions of the same list, but with different probabilities= of blocking legitimate traffic. - I set the list to update every 15 minutes after discussion with Michael, as= some of the lists update very quickly (every five minutes for some lists). I don't think there's any particular re= ason why a given update period is preferred. - I had code to create either a hash:ip or had:net ipset. The reason for thi= s is that aparently (if I remember the documentation correctly), looking for an IP address against a hash:net re= quires checking each of the possible containing networks (/32, /31, /30...). It thus takes significantly longer t= han checking against a hash:ip. As the majority of lists are only single addresses this seemed like a worthwhile= optimisation. - It's probably worth reviewing the list of blocklists. I would certainly re= move Alienvault, which seems to be defunct. Charles Brown suggested the 3COREsec lists, which look interesting.= This could be left to post-first release. As a note of caution, I found so= me interesting lists for blocking command and control servers which were licenced under terms that I thought would make it difficult to include i= n the IPFire distribution. - Longer term it may be worth adding the capability for a sources.local, but = again I think this is better left until post-first release. It may be worth adding a 'Do not edit this file' i= n the sources file since it could be overwritten by future updates. - I think IPFire now has four different ways of using the Spamhaus DROP list = (IPS, hostile networks, XD country code and IP Blocklist). When this is released it may be worth writing a blog= post or a wiki page on the advantages and disadvantages of each (or even a more general one looking at a= ll the different malware etc. facilities). Tim On 10/04/2022 19:47, Stefan Schantl wrote: > Hello Charles, > > thanks for a first look and your feedback. > > Now after you have put my attention to those "disable" value in the > sources file, I have to admit I totally have overseen this. > > When interpreting this field and the values, it seems has been designed > to automatically disable conflicting/obsolete sets in case such a set > is enabled. > > So for this feature I have go back to the drawing board and put some > attention to it. > > In the meantime please go on with testing and report any other issues. > > Best regards, > > -Stefan=20 >> Tim, Stefan, >> I have installed the ipblocklist feature. It looks great. >> I=E2=80=99m curious about the disable attribute in the sources file.=20 >> I have all the lists enabled, I would have thought enabling >> EMERGING_FWRULE would have the DSHIELD list automatically disabled. >> However, I am showing several hits on DSHIELD and I see 20 entries in >> ipset for DSHIELD. Is the disable attribute in sources there for >> informational purposes only?=20 >> Thanks for your excellent work on this feature, >> Charles Brown >> >> =20 > > --===============8657045111361712074==--