There’s no need to specify the protocol. Just drop it. And no, it won’t survive a restart. Depending on how your machine is setup you can add the line (without the ‘iptables’ at the start) to /etc/sysconfig/iptables, or just add it as an entry in /etc/rc.local - which is what I do.
I also noticed that in /etc/sysconfig/iptables-config is IPTABLES_SAVE_ON_STOP=“no” and IPTABLES_SAVE_ON_RESTART=“no”.
Would either or both of these set to yes make iptables entries survive a restart (I’m assuming they do, seems to from their description).
If yes to above, would saving the rules (including Fail2Ban as well I presume) cause Fail2Ban an issue after the restart? Since I’m not sure of how Fail2Ban tracks rules from a time-out (release) point of view, I’m concerned the a restart would restore Fail2Ban entries to IPTables that Fail2Ban doesn’t ‘remember’ putting there and so they would be permanent.
I wouldn’t automatically save, ever. It’s too easy to accidentally lock yourself out of your machine if you do that. And you’d probably find that, yes, fail2ban would get confused.
setup your iptables to first clear all rules, save it, then add what you want, save it, restart fail2ban. this will survive the reboot and will not restore any fail2ban banned ip’s. just make sure that everything is in the saved file. so something like the following:
add any ip addresses you want to ban permanently next
Set default policies for INPUT, FORWARD and OUTPUT chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT
Set access for loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
Accept packets belonging to established and related connections
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
add any other allow rules here
save
/sbin/iptables save
restart fail2ban
service fail2ban restart
this gets saved in /etc/sysconfig and gets reloaded after a reboot
what is really interesting is that you can use dynamic url’s (i.e. dyndns) in the firewall script and set up a cronjob to rerun it once a day or so. this allows support for those remote locations that do not have static ip addresses or don’t have vpn connections to the pbx.