From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim FitzGeorge To: development@lists.ipfire.org Subject: Re: [PATCH 0/5] ipblacklist: IP Address Blacklists Date: Sat, 21 Dec 2019 18:34:45 +0000 Message-ID: <9acd9e53-0ea2-40b1-34e3-01a4a60307d7@tfitzgeorge.me.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8427615610546674320==" List-Id: --===============8427615610546674320== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I've got my systems checking for downloads at 15 minute intervals and using If-Modified-Since. This all seems to be working OK. Responses to comments below: On 18/12/2019 12:07, Michael Tremer wrote: > Hi, >=20 >> On 17 Dec 2019, at 18:21, Tim FitzGeorge wrote: >> >> Hi, >> >> I think we've agreed on the following: >> >> - Checks to be made every 15 minutes, subject to per-list minimum rate. >> - Modify download to use If-Modified-Since rather than separate HEAD >> request. >> - Remove automatic blacklist. >=20 > I thought someone wants to counter my argument. This is not a dictatorship = :) >=20 >> >> other comments are below. >> >> Tim >> >> On 16/12/2019 22:20, Michael Tremer wrote: >>> Hi, >>> >>>> On 16 Dec 2019, at 20:06, Tim FitzGeorge wro= te: >>>> >>>> Hi, >>>> >>>> I've attached the current GUI screenshot. >>> >>> Thanks for that. >>> >>> I have a couple of suggestions/concerns about it: >>> >>> a) I am not sure what the value is about the top box that is called =E2= =80=9CStatus=E2=80=9D. It is basically a summary of the iptables output, but = will it help the user? A blacklist with more or fewer entries is not better o= r worse, blocking more packets isn=E2=80=99t better than blocking fewer. It i= s about the quality of the blocks. >> >> I agree that the size of the lists is not all that useful, but the >> information about the number of blocked packets can be an indication of >> compromise. It depends on the type of the list, but a list that targets >> C&C channels (e.g. the FEODO lists) should not show any input packets >> being blocked, unless one of the computers being protected is infected. >> Apart from the BOGON lists, none of the lists should show any output >> packets being blocked; again it's a potential indication of infection if >> otherwise. >=20 > The Shodan list will definitely show some activity unless you are behind CG= NAT. >=20 > Should we not have this rather in the logging section? >=20 > And these counters here will be reset when the firewall is being reloaded. = Should this data therefore not be collected from the logs so that you can go = back in time? That would be very important to identify any start of compromis= e. > That makes sense. I'll remove the status from this page and create a log page for the information. If anyone actually wants the iptables information it's available in from Firewall > iptables anyway. Do you think it makes more sense to show packets blocked in/out or packets blocked per source interface? The latter would of (limited) help in tracking down potential compromise. >>> >>> b) I would prefer to move the settings box to the top. If you like you ca= n show the size of the blacklists there and when they have been updated, too. >> >> I put the status at the top since it's usually what I want to see when I >> go to the page. Under normal circumstances I don't change the settings, >> so I'd rather not have to scroll past them to get to the information I'm >> actually interested in. The update times are just useful to show that >> the lists are actually being updated. The size is interesting to me, >> but as you say it probably won't help the average user, especially if >> you don't know which lists block individual addresses and which block >> nets (BOGON, DSHIELD and EMERGING_COMPROMISED). >=20 > See my comment on the order above. Splitting the page might make sense. >=20 > When you show size, does that mean lines in the blacklists? So it could be = networks or single IP addresses? Does it not make sense to count IP addresses= (i.e. 256 for a /24 network and so on) and put it in the table? It's lines in the blacklist. >=20 > I think I would only be interested in the size for two things: >=20 > a) Is there any chance for overblocking? i.e. does the list have 2 billion = entries which would be half the public IPv4 address space or so. I cannot rea= lly come up with a good example here. >=20 > Or >=20 > b) What is the performance impact/memory consumption of the list? It would be interesting to show the type (single address or net), number of entries and number of addresses; the first two affect performance, the second memory use and the latter the number of blocked addresses, but that's really only going to be of interest to a very small number of people, who can always do 'ipset list -t' to get the information. So I'll remove the size column. >=20 >> I originally had the status and settings in one list, but I decided that >> it was getting a bit messy and difficult to follow. I've attached a >> screenshot of a quickly hacked page. (Note that the status area only >> appears once the blacklists have been enabled.) >=20 > You are right. This is getting quite tight there. >=20 > You could write packets in/out into on column like 2k/1023, but see my conc= erns about this above. Actually I've come to the conclusion that the number of bytes blocked isn't all that important; it's sufficient to show the number of packets. >=20 >>> >>> c) I would suggest to remove the =E2=80=9Csafe=E2=80=9D column because th= at is a very hard summary of what the lists do. We should explain that on the= wiki. I guess this is too complicated to explain to our users in one sentenc= e and it needs at least a page of text. People who do not read that have you = just lost out. >> >> I agree that it's it's an over simplistic summary of the lists. I note >> that Tom Rymes has asked to keep it, but I think its only value is if it >> suggests to users that things are more complicated than they appear and >> therefore prompts them to read the Wiki. >=20 > I will reply to that separately. Looking at that reply, I think it makes sense to include a category column in both the settings and the log summary page - the former to help selection of which lists to use, and the latter as a help when deciding whether the information could indicate compromise or not. >=20 >>> >>> d) I do not understand what the =E2=80=9Cupdate check rate=E2=80=9D means= . I suppose we should show the update interval of the lists in the table and = just refresh them according to that. >> >> It's the minimum check period for updates. The system checks for >> updates at either the rate specific to the list or this rate, whichever >> is slower. This is a hangover from the early days, copied from the IPS >> updates. I suppose it could have a value for some people who may wish >> to lower the check rate, but I'm not sure that it has sufficient value >> to be worth keeping. >=20 > No, I would not let the user decide when and how often to update the lists. OK. I'll remove it. >=20 > Generally there is this argument internally how often some databases should= be updated. People with slow internet connections or volume based data plans= will find this rather expensive to update those lists too often. >=20 > If we ever want to go ahead with that in IPFire 2, there should be a global= switch for a =E2=80=9Clow data mode=E2=80=9D which then delays updating thes= e things. That makes sense. Maybe also the ability to set when downloads take place - but as you say that's for the future. >=20 >>> >>> e) Do we want to keep the automatic blacklists now? I do not think it wil= l actually improve the security of IPFire. >>> >> >> I'll remove them. I think they do have a use, in that they can detect >> someone doing a port scan and block them before they find an open port, >> but as you say there is also the possibility of a DOS. >=20 > How would this block a DOS? Sorry, I didn't make myself clear - there's the possibility that someone could cause a DOS with the automatic list by faking the source IP address and sending a few packets on a random port. >=20 > -Michael Tim >=20 >>>> >>>> I'll update the code based on our discussions, and submit an updated set >>>> of patches - I imagine there will have to be at least one more iteration. >>> >>> Let=E2=80=99s wait until we have come to decisions :) >>> >>> -Michael >>> >>>> >>>> Tim >>>> >>>> (No additional comments below) >>>> >>>> On 13/12/2019 23:11, Michael Tremer wrote: >>>>> Hi, >>>>> >>>>> Again my apologies for my late reply. Busy busy weeks. >>>>> >>>>>> On 8 Dec 2019, at 20:50, Tim FitzGeorge wro= te: >>>>>> >>>>>> Hello, >>>>>> >>>>>> It's my turn to apologise for being slow to respond - I've had a busy >>>>>> week, but I should have plenty of time over the next couple of weeks. >>>>> >>>>> No worries. Turns out we all do :) >>>>> >>>>>> I've made most of the comments inline, however I think Michael had a >>>>>> question (which I can't find now) about what happens if someone enables >>>>>> all the lists. One thing which would perhaps make this less likely is >>>>>> that the WUI tags the available lists with whether they're safe or not, >>>>>> with a footnote that safe means that the list only blocks malicious >>>>>> traffic. This won't guarantee that a user won't still try to enable a= ll >>>>>> the lists, but it should make them realise that they should think firs= t. >>>>> >>>>> We had a couple of features going slightly wrong or being =E2=80=9Cmisu= nderstood=E2=80=9D by some users. People still seem to panic when they see = =E2=80=9Clocal recursor=E2=80=9D. To this day I do not know why. >>>>> >>>>> We cannot make everything idiot-proof. And when some user if of that ca= tegory, they probably should shutdown their IPFire box, educate themselves an= d then come back again. So I do not want to limit people, but make things as = easy as possible. >>>>> >>>>> If someone enables all the lists, good luck with passing packets :) >>>>> >>>>>> I have considered replacing this tag with a risk high/medium/low and >>>>>> maybe adding a category (invalid/application/scanner/C&C or something >>>>>> like that), but that may provide too much information and dissuade them >>>>>> from actually following the links to checkout what the list actually d= oes. >>>>> >>>>> Can we have a screenshot of the GUI right now? I didn=E2=80=99t run the= code, yet. >>>>> >>>>> We should document the lists like we do it with the rulesets of the IPS= . People might ignore this, but that is on them. >>>>> >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>> On 05/12/2019 22:25, Michael Tremer wrote: >>>>>>> Hello, >>>>>>> >>>>>>>> On 4 Dec 2019, at 17:05, Peter M=C3=BCller wrote: >>>>>>>> >>>>>>>> Hello Tim, hello Michael, >>>>>>>> >>>>>>>> please see my responses inline... >>>>>>>>>>> >>>>>>>>>>> We could periodically update the blacklists on our main mirror (a= nd >>>>>>>>>>> wait for the network to sync it), make sure it is signed and write >>>>>>>>>>> a small downloader that fetches, validates and installs them. >>>>>>>>>>> >>>>>>>>>>> @All: Thoughts on this? >>>>>>>>>> >>>>>>>>>> I think there are a number of points here. >>>>>>>>>> >>>>>>>>>> Firstly, from the point of a third party using IPFire, is this rea= lly >>>>>>>>>> solving the privacy disclosure problem? There's no way round disc= losing >>>>>>>>>> your public IP address to someone you're downloading from; all thi= s does >>>>>>>>>> is change who that information is being disclosed to. For the us= er >>>>>>>>>> there's no way of knowing whether the source is more or less prote= ctive >>>>>>>>>> of the user's privacy than the blacklist provider. Indeed it won'= t be >>>>>>>>>> possible to know who the lists are being downloaded from until the >>>>>>>>>> download starts. >>>>>>>>> >>>>>>>>> There is a way: Tor. But that is a totally different story. >>>>>>>> Well, I see a third option on this: Use the mirror infrastructure we= already >>>>>>>> have. Every IPFire installation discloses its public IP address to o= ne of these >>>>>>>> servers sooner or later, so we do not disclose additional data if th= e blacklists >>>>>>>> were fetched from these. >>>>>>>> >>>>>>>> Needless to say, Tor (hidden services) would be better, but that is = a different >>>>>>>> story indeed. :-) >>>>>>>>> >>>>>>>>> The point is rather that a forget list can be sent instead of the = =E2=80=9Creal=E2=80=9D one. >>>>>>>> I did not get this. Forget? Forged?? ??? >>>>>>> >>>>>>> Yes, I meant to write forged, but auto-correct didn=E2=80=99t let me. >>>>>>> >>>>>>>>>> Secondly, latency; some of the lists are updated every 5 minutes. = While >>>>>>>>>> I've limited the maximum check rate to hourly, will the updates >>>>>>>>>> propagate quickly enough. For reference on my main system the 24 >>>>>>>>>> updates on the CIARMY list made 143 498 changes (additions or >>>>>>>>>> deletions). I've seem it do over 200 000. >>>>>>>> Yes, I observe that behaviour for CINS/CIArmy too. Unfortunately, th= ey do not >>>>>>>> document a recommended update interval anywhere, so we can only gues= s. >>>>>>>> >>>>>>>> Personally, more static lists seem to be preferable for packet filte= ring. Highly >>>>>>>> dynamic ones such as CIArmy should be done via DNSBL queries or some= thing similar >>>>>>>> - do we really want to have that list here? >>>>>>> >>>>>>> It is not really an option to implement a DNSBL into a packet filter,= but I get your point. >>>>>> >>>>>> One of the 'selling points' for an IP address blacklist is that it can >>>>>> respond quickly to new threats - or rather new attackers. While a new >>>>>> IDS/IPS rule needs time to analyse the threat, generate a rule and che= ck >>>>>> it, it's easy to add an address to a list. So, I think the CIArmy list >>>>>> is potentially useful for protecting home systems etc. with budget >>>>>> hardware, but I would be very careful about using it for a protecting a >>>>>> general access website. >>>>> >>>>> If they are very volatile, we should honour that and update them often,= too. >>>>> >>>>> It probably is more about false-positives being removed very quickly in= stead of adding threats very quickly. The average IPFire user is probably not= under threats like these to need to react very quickly. >>>>> >>>>> So I do not see much value in adding those lists and then updating once= a day. Does it have to be every 5 min? No. I would suggest 15 which should b= e good enough for everyone. >>>>> >>>>> Other lists should of course not be updated every 15 minutes when not n= eeded. >>>>> >>>>> Running every 15 minutes would allow us to retry downloading lists that= are on an hourly schedule if the download failed. >>>>> >>>>>>> >>>>>>>>> How did you come up with the hour? Will it be retried more often if= the download was not successful? >>>>>>>> One hour is the most common interval indeed, but adding some random = time might >>>>>>>> be useful in order to reduce load on the servers providing a blackli= st. >>>>>>> >>>>>>> Yes, definitely. Otherwise we will shoot down our mirrors. >>>>>> >>>>>> When I implemented that section of code, specifying the minimum check >>>>>> period in hours seemed to provide a convenient way of allowing a check >>>>>> period covering a wide range, with an hour as the fastest and a week as >>>>>> the slowest. I didn't looked at the CIArmy list until much later. Mo= st >>>>>> of the lists don't change nearly as much, but the CIArmy list is >>>>>> described as one that deliberately responds quickly. >>>>>> >>>>>> From my production system, for yesterday: >>>>>> >>>>>> The following block lists were updated: >>>>>> BLOCKLIST_DE: 24 Time(s) - 9341 change(s) >>>>>> BOGON_FULL: 1 Time(s) - 10 change(s) >>>>>> CIARMY: 24 Time(s) - 159134 change(s) >>>>>> DSHIELD: 7 Time(s) - 18 change(s) >>>>>> EMERGING_FWRULE: 1 Time(s) - 50 change(s) >>>>>> FEODO_AGGRESIVE: 24 Time(s) - 13 change(s) >>>>>> SHODAN: 1 Time(s) - 0 change(s) >>>>>> SPAMHAUS_DROP: 1 Time(s) - 0 change(s) >>>>>> TOR_EXIT: 24 Time(s) - 162 change(s) >>>>> >>>>> Very interesting statistics. >>>>> >>>>>> >>>>>> and my test system: >>>>>> >>>>>> The following block lists were updated: >>>>>> ALIENVAULT: 19 Time(s) - 5331 change(s) >>>>>> EMERGING_COMPROMISED: 1 Time(s) - 26 change(s) >>>>>> TALOS_MALICIOUS: 1 Time(s) - 36 change(s) >>>>>> >>>>>> That covers most of the lists. From the WUI, since 1 Dec: >>>>>> >>>>>> Blacklist Entries pkts bytes Last updated >>>>>> in in >>>>>> AUTOBLACKLIST 0 731 51144 Sun Dec 8 18:40:02 2019 >>>>>> BLOCKLIST_DE 28020 857 46735 Sun Dec 8 18:40:02 2019 >>>>>> BOGON_FULL 214 5255 189K Sun Dec 8 16:50:04 2019 >>>>>> CIARMY 15000 19774 976K Sun Dec 8 18:04:01 2019 >>>>>> DSHIELD 20 7992 321K Sun Dec 8 16:45:13 2019 >>>>>> EMERGING_FWRULE 1647 197 8383 Fri Dec 6 05:29:07 2019 >>>>>> FEODO_AGGRESIVE 7169 0 0 Sun Dec 8 18:50:07 2019 >>>>>> SHODAN 32 34 1530 Sun Dec 8 17:54:09 2019 >>>>>> SPAMHAUS_DROP 823 0 0 Fri Dec 6 18:22:35 2019 >>>>>> SPAMHAUS_EDROP 111 82 16433 Thu Dec 5 17:27:09 2019 >>>>>> TOR_EXIT 1055 0 0 Sun Dec 8 18:31:02 2019 >>>>> >>>>> This as well. >>>>> >>>>> Those are more packets than I would have expected. >>>>> >>>>>> >>>>>> (I've left out the pkts/bytes out fields which were all 0) >>>>>> >>>>>> Note that where possible I do a HEAD request first and then only >>>>>> download the list if the modification time has changed since the last >>>>>> check. For dynamically generated lists this isn't possible. >>>>> >>>>> You won=E2=80=99t need a HEAD request for it. You can include it in the= GET request. >>>>> >>>>> Have a look at location downloader where I use that. The server will re= spond with 304 and not send any payload. >>>>> >>>>> https://git.ipfire.org/?p=3Dlocation/libloc.git;a=3Dblob;f=3Dsrc/python= /location-downloader.in;h=3D1b5932d5822e03737d32b2a27816815b2f7e74dd;hb=3DHEA= D#l151 >>>>> >>>>>> >>>>>> If the download isn't successful it just gives up and waits for the ne= xt >>>>>> attempt (apart from the usual retries in the library). I probably >>>>>> should to change that so that it only applies the per list minimum >>>>>> update period in this case (specified in the sources file) rather than >>>>>> the user specified value as well. >>>>> >>>>> I think it is not the worst if an update fails. It might just happen ev= ery once in a while. >>>>> >>>>> So I would suggest to just re-run the script more often and when the mt= ime of the file is older than the threshold, a download is attempted. You can= use that timestamp for the GET request. >>>>> >>>>>> I already use a time offset on the downloads - when it's started from >>>>>> boot, backup restore or WUI enable, it checks to see if it's installed >>>>>> in the fcrontab, and if not adds itself at a randomly generated offset >>>>>> in the hour. >>>>> >>>>> That should potentially go to red.up, or if we can settle on 15 minutes= , I would consider that often enough to quickly update all lists after a rebo= ot. >>>>> >>>>>> >>>>>>> >>>>>>>>>> Third, bandwidth; while the downloads are fairly small (ALIENVAULT= is >>>>>>>>>> the largest at a few MB), there are going to be a lot of them. Ho= w will >>>>>>>>>> this affect the willingness of people to mirror IPFire? >>>>>>>> I do not consider this being a problem as we do not generate that mu= ch traffic >>>>>>>> to them. Of course, that depends on the update interval again. >>>>>>> >>>>>>> That depends on your point of view. >>>>>>> >>>>>>> I do not have a problem with this at all in my data center, but there= are plenty of people with a volume-based LTE plan or simply a 128 kBit/s con= nection. It will take a longer time to download the lists for them. We need t= o mind that. >>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Talking about the preference of packet filter and IPS, I prefer to >>>>>>>>>>> use the latter as well as it gains more insight in what kind of m= alicious >>>>>>>>>>> traffic tried to pass a firewall machine. On systems with low res= ources, >>>>>>>>>>> this might be problematic and removing load from the IPS can be p= referred >>>>>>>>>>> (make this configurable?!), on others, people might want to have = both >>>>>>>>>>> results. >>>>>>>>>>> >>>>>>>>>> You're only going to get one result for a packet whichever way rou= nd the >>>>>>>>>> IP blacklist and IPS are since whichever comes first will drop the >>>>>>>>>> packet before it reaches the second (well it would be possible to = put >>>>>>>>>> the IP blacklist first and get it to log and mark packets which ar= e then >>>>>>>>>> dropped after the IPS, but I think that's getting a little complic= ated. >>>>>>>>>> In addition I've seen the messages about the trouble marking was >>>>>>>>>> causing in the QoS). >>>>>>>>>> >>>>>>>>>> I think it's a 50/50 choice as to which is more valuable first; it= 's >>>>>>>>>> probably going to differ from packet to packet. For me the possib= ility >>>>>>>>>> of reducing the IPS load means I prefer putting the IP blacklist f= irst >>>>>>>>>> >>>>>>>>>> It should be fairly easy to add the choice of where to put the IP >>>>>>>>>> blacklist. I think it'll have to be in the main firewall script, = so >>>>>>>>>> it'll require a firewall restart, but it's not something that'll be >>>>>>>>>> changed often. >>>>>>>>> >>>>>>>>> I do not think that the user should choose this. If we cannot easil= y make a decision, how can our users do this? Not saying they are stupid here= , we are just giving them something so that they do not have to put the thoug= ht and research into things themselves and make their jobs easier. >>>>>>>> Agreed. >>>>>>>> >>>>>>>>> >>>>>>>>> I think performance matters. And if the IPS comes first, the most l= ikely case would be that we are seeing a SYN packet that is being scanned and= after that being dropped by the blacklist. It was pointless to even scan the= empty packet (TCP fast open aside). This is only different for other packets= with payloads. >>>>>>>>> >>>>>>>>> We would protect the IPS from a SYN flooding attack here at least a= nd from scanning more packets unnecessarily. >>>>>>>> So dropping packets from blacklisted IP addresses/networks before IP= S is it, then. >>>>>>>>> >>>>>>>>> I do not even think it makes sense to swap the order in the outgoin= g direction. >>>>>>>> Me too. >>>>>>>> >>>>>>>>> >>>>>>>>> What IPFire is lacking is a statistical analysis for those logs. Co= llecting more and more data isn=E2=80=99t helpful from my point of view. Only= if you are looking at a very specific thing.This is true, but I am not sure = if it makes sense to spend too much work on this. >>>>>>>> Based on my personal experience, firewall hits observed on a single = machine exposed >>>>>>>> to the internet are interesting, but the overall situation across mu= ltiple machines >>>>>>>> is even more interesting. Very quickly, you'll end on something like= a centralised >>>>>>>> logging server and custom statistical analysis here... >>>>>>> >>>>>>> Probably a project for IPFire 4.0 :) >>>>>>> >>>>>> Or use one of the existing services, like the DSHIELD client >>>>>> https://dshield.org/howto.html (subject to privacy concerns again). >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Personally, I consider Spamhaus DROP/EDROP can be safely enabled = by default. >>>>>>>>>>> I would love to see the bogon ruleset here, too (think about 8cha= n successor >>>>>>>>>>> hosted at unallocated RIPE space in Saint Petersburg), but that w= ill likely cause >>>>>>>>>>> interference if RED does not have a public IP address assigned. >>>>>>>>>> >>>>>>>>>> I can add a field to the options file that controls whether a list= is >>>>>>>>>> enabled by default. >>>>>>>> Thank you. :-) >>>>>>>>> >>>>>>>>> To stress the point from above again: We would then share all publi= c IP addresses of all IPFire systems in the world with Spamhaus and who is ho= sting their infrastructure. That can be considered a threat. >>>>>>>> This is my only objection against this patchset. Now, what can we do= about it? >>>>>>>> One possibility is to apply the patchset now and implement a custom = download >>>>>>>> source thing later on, or do that before releasing Core Update 139 (= or which version >>>>>>>> the patchset will be to) after we agreed on something. >>>>>>> >>>>>>> I do not see this being merged for 139. But that is not important. We= need to get it right first and then release it. >>>>>>> >>>>>>> As far as I know, nobody has tested this, yet. >>>>>> >>>>>> There are a number of people who have been running an earlier version >>>>>> which I shared on GitHub. There were a few early issues, but it seems >>>>>> to be OK now. >>>>>> >>>>>> https://forum.ipfire.org/viewtopic.php?f=3D27&t=3D21845 >>>>>> >>>>>> This version wasn't integrated into IPFire, so (for example) it insert= ed >>>>>> itself into the INPUT IPTables chain rather than having it's chains >>>>>> created as part of the firewall start-up script. >>>>>> >>>>>>> >>>>>>> I have huge concerns about the automatic blacklist. @Peter: What is y= our opinion on this? >>>>>>> >>>>>> >>>>>> While I implemented it, I'm aware of its potential to cause problems, >>>>>> which is why it has to be separately enabled. It's not caused me any >>>>>> issues at the default settings (blocks at over 10 packets per hour unt= il >>>>>> 1 hour has passed without seeing packets from the address), but I've n= ot >>>>>> used it on a site with publicly announced services. If I was going to >>>>>> use it on a web site I would want to, at the very minimum, drop the >>>>>> block period drastically. >>>>> >>>>> I suppose this is entirely unusable on an IPFire box in a data center t= hat hosts things. Let=E2=80=99s say our rack in Hanover. >>>>> >>>>> You will have hits from some broken IP stacks and people might just end= up on this without doing anything wrong. >>>>> >>>>> You can denial-of-service easily as well and I suppose without aggregat= ion of data from many many systems, it does not make sense to instantly block= addresses. And even then you probably would block an entire subnet. >>>>> >>>>> So I am not sure how I should feel about it. I do not think that it add= s anything because the packets would have been blocked anyways. >>>>> >>>>>> >>>>>> On the other hand, it's good at responding quickly. Usually I see only >>>>>> 1-2% of blocks from the automatic list: >>>>>> >>>>>> Reason Count % First Last >>>>>> CIARMY 2416 45 Dec 6 00:00 Dec 6 23:59 >>>>>> DSHIELD 1353 25 Dec 6 00:00 Dec 6 23:59 >>>>>> INPUT 1294 24 Dec 6 00:00 Dec 6 23:59 >>>>>> AUTOBLACKLIST 122 2 Dec 6 00:20 Dec 6 16:28 >>>>>> BLOCKLIST_DE 89 2 Dec 6 00:20 Dec 6 23:46 >>>>>> >>>>>> and sometimes none at all, but one one occasion it blocked over 8000 >>>>>> packets. Again I'm aware this is for a home system, which is rather >>>>>> different than from a Web server. >>>>>> >>>>>>>> If we do, I will have a look at the licensing stuff (DShield and Spa= mhaus do not >>>>>>>> seem to be problematic, as they are hosted on 3rd party servers, too= ). >>>>>>> >>>>>>> One of them will be, sooner or later. And one is enough I suppose. >>>>>> >>>>>> DShield (https://dshield.org/api/#threatfeeds) and firehol >>>>>> (http://iplists.firehol.org/) seem to host copies of most of the lists >>>>>> as well. >>>>>>> >>>>>>> I do not really want to overthink this - we didn=E2=80=99t do this wi= th clamav for example either. But it probably is a decision to be made by the= user what they want to enable and we should not enable anything by default. = So no data will be leaked as long as the user does not consent. >>>>>>> >>>>>>> -Michael >>>>>>> >>>>>>>> >>>>>>>> Thanks, and best regards, >>>>>>>> Peter M=C3=BCller >>>>> >>>> >>>> >>> >> >> >=20 --===============8427615610546674320==--