At Sat, 3 Apr 2021 12:30:46 +0530, Mayuresh <mayuresh%acm.org@localhost> wrote: Subject: Re: blocklistd: How to keep my dynamic IP from getting blocked > > Between these two: 1. Let blocklistd try to block and let npf overrule vs > 2. Let blocklistd not block. Isn't the latter more economical? I would include worrying about the economies of human understanding. If you have two layers of control were one can say one thing and another can possibly reverse the first's decision, then perhaps that is more complex and more difficult to understand, especially during an emergency debugging session. However if you have one layer that entirely controls the other (with respect to whatever features that controlling layer controls), then you should only have to look in one place and understand one set of conditions and rules to figure out what is going on. So if you're going to use blocklistd to manage and control network abusers, and that's going to be manipulating your firewall rules, then I would say that you want to manage every aspect of what blocklistd does at the blocklistd layer. I.e. make the firewall entirely subservient to blocklistd w.r.t. what responsibilities you've assigned to blocklistd. Perhaps as an allegory, when I first started using network level packet filtering firewalls I already had a long experience with using TCP Wrappers (i.e. libwrap with /etc/hosts.deny) to control access to services. However I continued to use TCP Wrappers as I introduced firewalling to my servers, and as a result I found that I could rapidly confuse myself when something didn't behave as expected if I didn't keep the domains of responsibility between these two access control features quite well separated. That all said, there are still a million ways to cut a cake, and not necessarily any one better than the other, especially if you're just going to eat the whole thing anyway. In this example you could even modify the easily modified back-end blocklistd-helper script to filter out those actions you don't want it to take, perhaps also controlling it with yet another configuration file or list, etc., etc., etc. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpxeKbtHHMhl.pgp
Description: OpenPGP Digital Signature