Is this a fail2ban weakness?

[bowlesj]

Hi, I am using fail2ban and I am also using SSH key authentication to get into my VPS. I have not changed the SSH port yet but I will be doing that very soon (today or Monday). Fail2ban gives me 5 tries to log in (more than enough if I am off site at a different IP address). Because my home computers are very secure I am using a macro to run Putty and WinSCP to log in (the delays between screens are 1 second so it has run flawlessly every time (so far) but with 5 tries to log in there is no worry). The first thing this macro does is pull up my public IP address with a google search "My IP Address". When it changes I log in and set up fail2ban to make this new IP address an ADDITIONAL exception. I do the same with the phpMyAdmin config file and I backup these config files to my home machine. Logging in with this macro has been very educational. I have learned that my IP address changes every 3 or 4 days. I thought there was no problem until this question occurred to me this morning. "Is it possible for a hacker to be using a public IP address provided by my service provider such that they have already been blocked by my Fail2Ban program in the iptables and I will some day get this new IP address and I will be locked out for the length of time I have set up in the Fail2Ban program (In other words the iptables will not even allow me to try and log in)?". I am assuming the answer to this question is yes and I should stop using fail2ban. Am I correct?

Thanks,
John

[Celauran]

Possible? Yes. In theory it could happen. How likely a scenario that is, on the other hand, is a whole other matter.

[bowlesj]

I guess once I get the SSH port changed to something other than 22 the odds of my getting locked out drop even lower since all the root failed attempts will no logged be logged by fail2ban.

Although the risks are low of this happening I am currently assuming that the only reason to use fail2ban is to reduce the /var/log/secure log file size. I am also thinking that once the SSH port is changed to a number other than 22 and all the root login attempts are gone from the /var/log/secure log file (leaving only the invalid user ID login attempts to make this log file grow in size) the benefit of using fail2ban for reducing log size is not worth the risk. I am thinking that rolling the logs (which I don't know how to do yet) is probably a better method of managing the log sizes. Having said this, fail2ban does have methods of monitoring other logs (mainly Apache). Maybe Google searches such as "how to monitor your log files" or whatever would help bring to light more reasons to use fail2ban. I did one search along this lines and it showed me how to set up fail2ban for Apache but it did not really tell me what it buys us. I am pretty sure this is on my list as a low priority item. Maybe when I finally get back to reading this link again I will have some more knowledge which I can use to better decide if I should keep using fail2ban or to reinstate it.

[Vegan]

https://www.fail2ban.org/wiki/index.php/Main_Page

fail2ban is written in Python so make sure that interpreter is available