WEB UI - Fail2Ban version 0.11 supports incremental bantime, Plesk UI does not

[trialotto]

Username:

TITLE

WEB UI - Fail2Ban version 0.11 supports incremental bantime, Plesk UI does not

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.49.2
OS version: Ubuntu 18.04 x86_64
Build date: 2023/01/10 23:00
Revision: c825df0ebc392580c3443ca51b28c6cb88be266d

PROBLEM DESCRIPTION

Plesk UI does not allow to set up incremental bantime, supported by Fail2Ban version 0.11

This incremental bantime is very valuable, in order to keep any system efficiently running.

STEPS TO REPRODUCE

1 - go to /etc/fail2ban
2 - open jail.local
3 - just add to one of the jails :

# default bantime 1h
bantime = 3600
# incremental banning:
bantime.increment = true
# default factor (causes increment - 1h -> 7d 14d 28d 56d ...):
bantime.factor = 168
# max banning time = 5 week:
bantime.maxtime = 5w

4 - reload fail2ban : service fail2ban reload

One can see in fail2ban.log that the jails are loaded without any issues.

ACTUAL RESULT

see above

EXPECTED RESULT

Plesk Team, could you be so kind as to add the UI controls that enables people to

1 - opt for standard bantime or incremental bantime
2 - fill in the desired and required values
3 - use a default factor (read: bantime.factor) of 24 (but adjustable for those that want to change the value)
4 - use a default maxtime (read: bantime.maxtime) of 4w (not adjustable, this is a good value by any standards)

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Answer the question

 

[Peter Debik]

Hi @trialotto, this is not a bug, but a feature request. Please create it as a feature request on Feature Suggestions: Top (1940 ideas) – Your Ideas for Plesk

 

[trialotto]

Hi @trialotto, this is not a bug, but a feature request. Please create it as a feature request on Feature Suggestions: Top (1940 ideas) – Your Ideas for Plesk

@Peter Debik

I know that is not a "bug", but there is the emotion that "feature suggestions" do not result in concrete action and/or development.

Moreover, the "issue" of not being able to throttle Fail2Ban is direct or indirect : resource overusage when being under attack, even though the incremental bantime option of Fail2Ban can mitigate this exposure (of Plesk) to resource overusage.

Nevertheless, you are right ...... it should be in another thread (and I am not posting it again in that other thread).

Kind regards....

 

[Peter Debik]

but there is the emotion that "feature suggestions" do not result in concrete action and/or development.

I admit that this is an issue. I've heard the same from other users. But it is only a perception, because so many Uservoice requests clog up the pipeline that are very minor stuff. We've have a total of 5,600+ requests so far. Approx. 3,100 were not feature requests or were declined for lack of popularity. But 1,000+ were already available or have been made available.


Uservoice is actively managed on a daily basis. We also try to merge feature requests that may be similar or the same but formulated differently into single requests so that their popularity becomes visible.

Plesk is also currently working intensively on the most requested features. These are quite complex though. Of the top feature "Synchronize Plesk Failover" two major components were made available last year: The centralized database and network file system. There are also requests that are more or less an ongoing development process. They may never reach a "completed" state, like the inclusive language request, because there is always something that needs to be changed or added.

One thing however is for sure: Staff is looking at the requests and considers them seriously. Every single one is reviewed, and probably more than once. It makes a lot of sense to post ideas to Uservoice.

 

[Kaspar]

Good to read that suggestions on UserVoice are actively been look at and evaluated. I am also glad you acknowledge that fact that to some users (myself included) UserVoice seemed rather dormant, with little activity or feedback (from Plesk). Creating the perception that UserVoice suggestions are not being worked on. At the same time I realize managing all UserVoice suggestions is a monstrous task. Lately however, I did notice a bit more activity from Plesk staff on UserVoice. So kudos to you and the Plesk team for that. Keep it up

@trialotto I never knew about fail2ban's incremental bantime option. Seems like a very valuable feature. So thank you for bring it up. I'd be more than happy to give this feature/suggestion my vote if you post it on UserVoice. I don't know how Plesk evaluates which suggestions from UserVoice make it in to a new release. With the many, many suggestion currently in UserVoice that must be a hard pick. But I am sure thats not solely based on "votes", I imagine things like feasibility, development cost (resources) and use(r) potential are part of the equation too. With that in mind i'm optimistic that this feature will find it's way into Plesk even without a gazillion votes.

 

[Maarten]

It's a very handy feature, which I've been using for some time now:

[plesk-wordpress]
enabled = true
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 5w
ignoreip = 127.0.0.1/8 ::1

Once it's on Uservoice, I'll vote for it!

 

[trialotto]

It's a very handy feature, which I've been using for some time now:

[plesk-wordpress]
enabled = true
bantime = 1h
bantime.increment = true
bantime.factor = 24
bantime.maxtime = 5w
ignoreip = 127.0.0.1/8 ::1

Once it's on Uservoice, I'll vote for it!

@maartenv

Thanks for providing a sample configuration.

There are two items in your configuration that need some elaboration, at least in my opinion.

The bantime.factor config setting can be anything, in your case it is 24 - that means incremental bantime of : 1d, 7d etc...

In essence, the bantime.factor can "mimick" permanent bans - it is not the same as a permanent ban.

In the case of specific jails, for instance jails that combat bruteforcing, one should set this bantime.factor value higher in order to create a ban that is really persistent, but without the disadvantages of the permanent ban of Fail2Ban (read: applying a -1 to bantime is equivalent to a permanent ban).

The bantime.factor and higher values thereof are certainly preferred over the permanent ban.

With respect to the setting

ignoreip = 127.0.0.1/8 ::1

it is recommend to NOT include that in any jail, but

1 - to be aware that all (or almost all) default jails in Plesk are ignore local IPs and local network addresses, (and)

2 - to be safe and to put local IPs and network addresses in the "trusted IP" section, if they are not present there already.


Kind regards.....

 

[trialotto]

I admit that this is an issue. I've heard the same from other users. But it is only a perception, because so many Uservoice requests clog up the pipeline that are very minor stuff. We've have a total of 5,600+ requests so far. Approx. 3,100 were not feature requests or were declined for lack of popularity. But 1,000+ were already available or have been made available.

View attachment 22779
Uservoice is actively managed on a daily basis. We also try to merge feature requests that may be similar or the same but formulated differently into single requests so that their popularity becomes visible.

Plesk is also currently working intensively on the most requested features. These are quite complex though. Of the top feature "Synchronize Plesk Failover" two major components were made available last year: The centralized database and network file system. There are also requests that are more or less an ongoing development process. They may never reach a "completed" state, like the inclusive language request, because there is always something that needs to be changed or added.

One thing however is for sure: Staff is looking at the requests and considers them seriously. Every single one is reviewed, and probably more than once. It makes a lot of sense to post ideas to Uservoice.

@Peter Debik

I really appreciate this response!

With respect to

hese are quite complex though. Of the top feature "Synchronize Plesk Failover" two major components were made available last year: The centralized database and network file system.

I have to admit that it is a leap forward, but these 2 components do not add value, given the facts that

1 - a centralized database and/or (distributed) network file system could have been realized by any well-seasoned sysadmin and should NOT be implemented by any sysadmin that is not familiar with the two topics,

2 - the (distributed) network file system is not well-adapted to cloud deployment situations, to my regrets,

3 - any cloud environment has the possibility to use "file shares" (or disks) across many (virtual) servers, hence making the (distributed) network file system a bit obsolete in a cloud environment,

4 - the centralized database has no value at all, as long as there is no possibility to use secure SQL connections,

and the QUESTION is therefore what should be prioritized by Plesk Team : the two major components are a leap forward, but also indicate a development of components that are dependent on development of other components with higher priority, such as the secure SQL connections.

As far as I know, the secure SQL connection is still absent, making it a bit cumbersome (but not impossible) to create any failover infrastructure.

I am well aware that this is also a matter of choice, since any well-designed multiserver Plesk infrastructure could cause Plesk license mayhem!


In short, I do acknowledge that development (or prioritization thereof) is not that straightforward and that most people tend to forget that there are specific requirements for development of components, but there are some major improvements to be made to Plesk - it is better to be ahead of the game!

In addition, I still do not understand why Plesk does not allow (specific) forum members to actively contribute to development, since there are at least a couple of forum members willing to "donate" knowledge and solutions, as opposed to posting feature requests alone.

Kind regards....

 

[Kaspar]

[...] I still do not understand why Plesk does not allow (specific) forum members to actively contribute to development, since there are at least a couple of forum members willing to "donate" knowledge and solutions, as opposed to posting feature requests alone.

If I am not mistaken they already do. For example I've provided feedback trough a number of surveys and I've been interviewed, about two years ago, to share my thoughts and experience more in depth. Which got initiated trough this topic and was actually a very pleasant session with Plesk staff. I regularly come across feedback requests from Plesk on a verity of topics. Both here on the forum (like these topics [1], [2], [3], [4] and [5]) as well as trough notification in Plesk itself. There is also the user experience research program in which you can participate. All in all I would argue that Plesk isn't shy about asking for input and feedback.

 

[trialotto]

If I am not mistaken they already do. For example I've provided feedback trough a number of surveys and I've been interviewed, about two years ago, to share my thoughts and experience more in depth. Which got initiated trough this topic and was actually a very pleasant session with Plesk staff. I regularly come across feedback requests from Plesk on a verity of topics. Both here on the forum (like these topics [1], [2], [3], [4] and [5]) as well as trough notification in Plesk itself. There is also the user experience research program in which you can participate. All in all I would argue Plesk isn't shy about asking for input and feedback.

@Kaspar,

Even though I appreciate your reply, it is not a reply to the comment that I posted.

Sure, I have read the links provided by you and my honest thoughts were "awful", "not again", "ah! that failed and withdrawn extension", "bloody surveys".


The fact is that one cannot contribute to Plesk, for several reasons :

1 - specific parts of Plesk source code are obfuscated, so one cannot do anything with that,

2 - there is not a pull/push system to get or submit code or contributions to code,

3 - battle-hardened and well-tested (simple) code or config improvements are not implemented by Plesk Team, not even after years,

4 - some other reasons that have been discussed privately, not intended for public sharing.


I am not really bothered about it, since I have been spending a lot of time on Plesk development (in the past) and if somebody does not want to do anything with my offer to share any contribution for free, then that is fine by me - I literally stopped developing (and that will not change).


Nevertheless, I need to be honest.

You are right that Plesk has improved in many ways to get user input and feedback.

My whole point was that Plesk did not improve anything in the area of contributions other than user input or feedback.

My whole point is a bit irrelevant, since Plesk cannot be composed of all kinds "loose contributions" - Plesk Team would lose valuable time when being required to check each contribution, with that valuable time better spent on uniform development of the Plesk instance (for many platforms).

However, the loss of valuable time also applies to asking Plesk users to provide user input or feedback ...... there is always somebody looking at the car, but there are less people looking at the engine - if that engine does not work properly, then any comment or compliment about the car is futile and useless.

In my humble opinion, Plesk "as is" looks fine, but I want to go faster and further - the engine needs some fine-tuning.

Otherwise, it will be "just" Plesk, no matter how many times Plesk Team will ask me what I think about Plesk.


Kind regards....

PS Out of curiosity, you state that you have contributed with surveys / interviews, but how many times did you click the "Plesk feedback" banner away? I cannot imagine that I am the only one clicking that away and/or deleting those "terrible reminder mails"
!