On Mon, 2010-08-09 at 15:29 +0000, Joseph L. Casale wrote:
http://www.fail2ban.org/wiki/index.php/Fail2ban:Community_Portal "Question about persistant IP bans over restart"
I think you need to adapt the example to CentOS/RH
Yeah, I saw that one and implemented it. I think I have to rewrite the action scripts my jails use. The odd part is the initial parsing behavior on a real restart such as a reboot, it parses the logs and only catches some of the total potential hosts that can trigger the ban. Prolly just a bug...
Really, unless your ban time is shorter than your logrotate, or you configure it to read some of the rotated logs there is a problem with maintaining the banlist on restarts if you don't do as the orig script does and del the iptables rules when exiting. If the process sh!ts the bed you still have an issue which wouldn't get cleared up until the next restart, but with the parsing issue you're left with an incomplete ruleset:/
Anyone know of a more elaborate app that does what fail2ban does but maintains a better state inbetween restarts?
--- Yea you seem to be right as that is what I got also and threw it in the trash can.
I'm not telling you what to do that is your business but I say utilize what is in the OS itself to do it. You can do a shell script to go through the iptables logs and get the bad ips have it add to iptables it self then iptables-save. A lot less in size as compared to f2b also. Or block all networks like china,japan,india and so on. Can get these from ICANN.
Your better off at doing this at the core router level as it can be done. As in blocking whole networks. Just thinking a buffer overflow could trigger a clean log of f2b ips. I think it's in the layering of complexity that will get you in the end. A lot of log writing will eventually kill the machine. Iptables can it self log at a rate of 100 - a burst of 150 TPS on a 10K Mirrored Array bringing it to it's knees. That is logging MulticastDNS
John