@UFHH01
In
this post you seem to want to go into detail.
Let´s do that, shall we?
First of all, in the before mentioned post, you created a section "For example" and continue to explain why specific codes are associated with specific cases.
In the explanation, you suggest that some of the cases should not automatically lead to rejection or banning.
You are right, for sure.
Since I did not want to start a discussion, I did not mention at first that your failregex is too strict, in the sense that specific codes should not be incorporated in failregex.
I simply do not want to bash an excellent hint for creating an additional jail that can partially (!) resolve these type of "attacks" (what is in a word?).
In essence, one can prevent false negatives (IPs are banned but shouldn´t be) by removing specific codes from the failregex (and not include them, as you proposed).
Second, the following
The "findtime" for 12 hours is an extra long setting for spam - bots, which come back on a regular basis ( mostly twice a day ) with thousands of different IPs ( often enough dynamic ones! ).
is, well, a bit thoughtless, a term that you yourself use.
Fail2Ban is not only using the findtime setting as the interval in which to count the number of attempts that match a filter.
In fact, Fail2Ban is also using the findtime as the interval
after which ban actions are being executed.
For instance, a findtime of 10 minutes implies that IPs, matching a filter, are banned
after the ten minutes have expired.
In short, having a 12 hour findtime will allow a time window of 12 hours for hack attempts.
That is really not recommended.
Third, the following
sorry... but this is a rather thoughtless remark. For longer bans, we have the "recidive jail", which definetly should have ban-times longer than a month. There is absolutely no need to have longer bans than 24 hours for the other jails, especially not, when you think about dynamic IPs, which change every 24 hours. ( and no... I won't discuss that, because it's simply logical! ).
is not correct, let´s call it thoughtless again.
In fact, the recidive jail does not work properly.
In the case of the current type of "attacks", Fail2Ban should ban them with the recidive jail, but does not.
This is the result of the other jails banning and unbanning specific bad IPs, due to the settings of maxretry, bantime and findtime.
A long story short, the recidive jail should block all current type of "attacks" but actually does not.
Have a look at the fail2ban log and investigate all mail related log entries and you will see what I am trying to say.
All of the above is closely related to my remark that all Fail2Ban jails are interrelated and that one should take care that they are aligned properly, to allow Fail2Ban to work efficiently.
Fourth, with respect to the last quote, I must emphasize the facts that
- it is not about dynamic IPs, most of the bad IPs in the current type of attacks are related to static IPs,
- the bad IPs do not change, there are lot of identical bad IPs across various (attacked) servers,
- the attacks are very likely to be associated with or caused by malware installed on "local PCs or Desktops", probably internet café´s (primarily in the Far East)
and you verify this by simply
a) leave the postfix or qmail jail disabled for a couple of hours, "grep" into the relevant logs to find the relevant IPs, "sort" all bad IPs in order to create an unique list: a pattern exists
b) ask "antivirus companies" for information or access the information provided by them, if you have access
Fifth, note that an unique list of bad IPs, associated with the current type of "attacks", does
1 - not show much variation with respect to IPs used by the "attackers" (read: no statistical significant variation, when compared to other types of attacks)
2 - show some problematic bad IPs (read: thousands of attempts per one unique bad IP)
3 - show a lot of bad IPs that are associated with 5 or less attempts (when having maxretry roughly at 3 to 4) or with 10 or less attempts (maxretry at Plesk default setting 5)
and, as such, evidence exists
- from point 3 that Fail2Ban does it´s job (properly) for most IPs
- from point 2 that Fail2Ban failregex for postfix (or qmail) jail is not properly configurated, some attempts "work around" the default Plesk filters for Fail2Ban
- from point 3 that Fail2Ban can improve it´s banning performance by fiddling with maxretry settings (lowering maxretry, even if the default findtime of 10 minutes is used)
and in addition, all of the above results significantly improve when
- using a different Fail2Ban failregex (not a custom, additional jail)
- using a longer findtime (with the improvements rapidly decreasing if the findtime becomes higher than 3600)
and these results are not simulated, but are a summary of what actually happens on a common, standard server.
Sixth, the final conclusion: everybody has to do what he or she wants.
This discussion is not worth it.
Regards.....
Facebook
Twitter
