TCP connections are generally considered to be proof against IP spoofing.

If pam_set_item(sshpam_handle, PAM_RHOST, pam_rhost); was set in the the MariaDB pam plugin there might be a way to implement this as a PAM module.

This seems like it would be a highly desirable feature, and even one that should be shipped with the default installation set to 5 failed logins per user/ip and then lockout for 300 seconds. So the default installation is as secure as possible.

What is needed to get this assigned to someone?

What's your use case?

The default installation listens to only the localhost interface. Most common cases the exposure of a database port is to only the LAN that's needed. Common connections are for applications can have large complex passwords immune to brute forcing. TLS is there for interfaces with stricter requirements. You did inspire me to write https://github.com/MariaDB/server/pull/631 however I'll probably rewrite it to pull out the real origin from vio rather than the host field in the user table. Alternately fail2ban has a MySQL password filter. There's very little motivation to add more complexity to the authentication path of MariaDB without making it general like PAM.

This is quite similar to MDEV-13096.

Our database servers are in the cloud and have an external IP address. Several of the accounts, including root, can be accessed remotely and we don't normally restrict the ip addresses they can be logged in from because of Google App Engine coming from a wide range of (changing) IP addresses. SSL is required, tls 1.1 min. Yes, we have large (30 char) high entropy passwords on everything and require certificate validation.

So, because our mid-tier is on Google App Engine, we can only restrict to a large range of possible IP addresses, and these keep changing... so user@% is our use case. In our use case, end users never type a password (except under edge cases) as they are authenticated by google, and we use that authentication to lookup the database credentials.

We have noticed that various servers (some apparently from hong kong and eastern europe where we have no customers) are trying repeat attempts to brute force attack root@someip and mysqld@someip. We would like to lock these ip addresses out for a long time after only a few number of failed login attempts. For our use case, we might lock out for 6 hours after 5 failed attempts.

I agree the very complex password largely solves the problem for now, but I would like to make it even more difficult by adding the above capability if at all possible. It is a very common practice in computer security to lock for X time after Y failed password attempts... we are just tweaking the model so it applies to user@someip so that denials of root@12.12.12.12 doesn't prevent root@12.13.14.15 from legitimately logging in.

Let's consider it's done in MDEV-7598. Not exactly as described here, but close enough.

It is unclear to me what was actually implemented by looking at the other MDEVs.
Can you point me to the MDEV or anything that describes the final implemented solution?
Does it count retry's only for user@someip as described? I can't use it if brute force of root@somebadip blocks root@agoodip

It's documented here: https://mariadb.com/kb/en/library/server-system-variables/#max_password_errors

It works per user account, that is, per one row in mysql.user table.