Hi, Brian J. Murrell wrote: > So, just to make sure I have this right, disregard all of the previously > discussed solution WRT to actions, etc. and simply add to the shorewall > blacklist file: > > +fail2ban > +fail2ban_perm > > and then create the two ipsets with: > > ipset -N fail2ban_perm iphash > ipset -N fail2ban iphash > > and then have fail2ban simply add and remove entries from the ipset, > correct? > > I can achieve my goal of allowing connections *to* blacklisted sites to > be permitted by adding the following hack to started: > > $IPTABLES -I blacklst -m conntrack --ctdir REPLY -j RETURN > > and I'm seem to be good to go. > > Do I have that all correct?
Well, I don't like to change the way any existing features work: - You have to remember, that you have changed something. - If you ever want to use a 'traditional' blacklist, you cannot. - Any changes upstream will make may break your firewall. So I wouldn't try to change the blacklist feature, instead I would implement my own custom blacklist (using the rules file or whatever is needed but without manipulating any existing rules). But this is just a design question. If you are fine with your changes and they work the way you want it, go with it. Two annotations: > My goal here is to add a drop/blacklist rule, dynamically, when fail2ban > detects a host is doing bad things. A portscan is a good example to use > for "bad things". But I also want to block/drop any established > "inbound" connections that are open, for example to shut down a > brute-force attacking of SSH that might have started before the portscan > started. Have a look at the deprecated BLACKLISTNEWONLY or the new BLACKLIST option: http://www.shorewall.net/manpages/shorewall.conf.html > The collateral damage here though is for example, IRC servers that I > want to connect to that want to do a portscan of me to make sure I'm not > an open relay. They end up blacklisted in the dynamic chain with no > regard to whether the packets it's dropping are from outbound > connections or inbound. That sounds like you are trying to fix the wrong problem: If a legitimate source will get blacklisted while doing an authorized port scan, your portscan rules are way too sensitive. > As an aside I wonder if it's a worthwhile feature to have a setting to > allow connections *to* blacklisted sites and to add the above to the > blacklst chain if that setting is enabled. I am still wondering why somebody wants to block every connection attempt from a source but still want to be able to contact that source at all. Can you share more use cases with us? -Thomas ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
