Bug #89155 | Connection-control exhausts all max_connection resources | ||
---|---|---|---|
Submitted: | 9 Jan 2018 3:50 | Modified: | 16 Jan 2018 9:10 |
Reporter: | kfpanda kf | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Connection Handling | Severity: | S2 (Serious) |
Version: | 5.7.17 | OS: | Any |
Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
Tags: | Connection-control |
[9 Jan 2018 3:50]
kfpanda kf
[9 Jan 2018 5:35]
MySQL Verification Team
BUG 25054521 - CONNECTION_CONTROL: MAKES IT TOO EASY TO DOS AS MAX_CONNECTIONS HIT
[16 Jan 2018 9:10]
MySQL Verification Team
Hi, Thanks for your report, we are already aware of this but the consensus is that this is not a bug. The rationale behind it is that one should not have connect control plugin on an WAN facing server that have grants open to %. The % host should never exist in production environment. The reason why plugin keep the connection that long is to slow down the brute force attacks and we provide min/max delay configuration to configure per your dba wishes. All in all, closing this as non-bug. Thanks Bogdan
[12 May 2022 11:20]
Rineez Ahmed N
I have to strongly disagree with the resolution given here. I can accept that the connection control plugin need to delay the next login attempt to make brute-force attack harder, but at the same time this plugin must also be able to prevent that "waiting client" from consuming a mysql connection resource. The resource consumption in this case is unacceptable. If a client makes more failed attempts than threshold, why not just reject the next connection attempt from same client until the delay is passed? Why allow it to make a connection and then stay connected during the whole waiting time allowing it to hold a valuable connection resource for such a long time? I mean it must work like a connection throttling, not like queue. Please please reopen this and consider revising this behavior of the connection control plugin. Love & Regards