• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs Plesk places F2B rules on front row

mr-wolf

Silver Pleskian
Plesk Guru
TITLE:
Plesk places F2B rules on front row
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk 17.5.3, Ubuntu 16.04 LTS
PROBLEM DESCRIPTION:
When I enable the F2B Plesk module it will create a rule in front of all the other rules.

I think it should insert itself a bit later in the chain.
This way it is taking processing power without anything to gain.​
STEPS TO REPRODUCE:
Enable the Plesk Firewall module
Enable the Fail2ban module​
ACTUAL RESULT:
Code:
-A INPUT -p tcp -m tcp --dport 22 -j f2b-SSH
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
EXPECTED RESULT:
I would expect at least this....

Code:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j f2b-SSH

or even better

Code:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...
...
...
....
-A INPUT -p tcp -m tcp --dport 22 -j f2b-SSH
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

The code that inserts the F2B-rules should seek a more strategic position so it will not become a performance hit to the firewall and make it take too much processing power.
Most of the traffic is already established and shouldn't need rechecking​
ANY ADDITIONAL INFORMATION:
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
Confirm bug
This behavior is not a bug. Moreover, it is behavior of 3rd-party software – fail2ban.
What is described is a feature request. Please post feature requests to UserVoice
On the other hand, it is quite a questionable feature – allowing malicious user to maintain connection to server (due to ESTABLISHED or RELATED state) is a dangerous decision.
 
Hi Igor,

In the mean time I found out that it's indeed an F2B decision to put it there....
F2B can't add any connection until a daemon detects some kind of error/misbehaviour. The daemon will then write something in the log and should break the connection.
The reason it may put something in front of the "ESTABLISHED" rule is because some daemons don't. I know that most daemons are breaking off connections and would therefore not need to be put in front of it.

For SSH the F2B is for sure totally unnecessary and inefficient. iptables can do that much better AND in real time.
Using this for ages.....

Code:
-A bruteprotect -m recent --set --name BRUTEFORCE --rsource
-A bruteprotect -m recent ! --update --seconds 60 --hitcount 4 --name BRUTEFORCE --rsource -j RETURN
-A bruteprotect -j LOG --log-prefix "[DROP BRUTEFORCE] : " --log-tcp-options --log-ip-options
-A bruteprotect -j DROP

-A ownservers -s 36.91.3.179/32 -j logaccept
-A ownservers -s 39.20.87.42/32 -j logaccept
-A ownservers -j RETURN

-A logaccept -j LOG --log-prefix "[ACCEPT] : " --log-tcp-options --log-ip-options --log-uid
-A logaccept -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ownservers
-A INPUT -p tcp -m tcp --dport 22 -j bruteprotect
-A INPUT -p tcp -m tcp --dport 22 -j logaccept
 
Back
Top