MySQL Bugs: #16227: Limit the number of unauthenticated users from the same IP address

Bug #16227	Limit the number of unauthenticated users from the same IP address
Submitted:	5 Jan 2006 15:01	Modified:	2 Feb 2012 12:31
Reporter:	Cyril Bouthors	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	4.1	OS:	Linux (Debian GNU/Linux)
Assigned to:		CPU Architecture:	Any

Description:
Short: limit the number of unauthenticated users from the same IP address

Long:

We've recently suffered downtimes because our MySQL servers have been
attacked, someone has simply opened several thousands TCP connections
to the port 3306 of our servers and waited without authenticating.
The servers reached their max_connections within a couple of seconds
and stopped accepting new connections.

We've blacklisted the IP address but the same thing keeps on happening                                                                                                                                                                     
again and again with different IP addresses. My company provides
public MySQL accesses so I can't deny such connections with my
firewall.

I'm not even sure that it's an aggressive attack, it might just be a
bug in a script of one of our clients that keeps on opening
connections in an endless loop in a certain condition is not met.

MySQL should be able to prevent itself from such attacks by limiting
the number of unauthenticated users from the same IP address.

FYI, the processlist output during the attack looked like:

+-----+----------------------+-----------------+----+---------+------+------------------+------------------+
| Id  | User                 | Host            | db | Command | Time | State            | Info             |
+-----+----------------------+-----------------+----+---------+------+------------------+------------------+
| 437 | unauthenticated user | localhost:42562 |    | Connect |      | Reading from net |                  |
| 438 | unauthenticated user | localhost:42563 |    | Connect |      | Reading from net |                  |
| 439 | unauthenticated user | localhost:42564 |    | Connect |      | Reading from net |                  |
| 440 | unauthenticated user | localhost:42565 |    | Connect |      | Reading from net |                  |
| 441 | unauthenticated user | localhost:42566 |    | Connect |      | Reading from net |                  |
| 442 | unauthenticated user | localhost:42567 |    | Connect |      | Reading from net |                  |
| 443 | unauthenticated user | localhost:42568 |    | Connect |      | Reading from net |                  |
| 444 | unauthenticated user | localhost:42569 |    | Connect |      | Reading from net |                  |
| 445 | unauthenticated user | localhost:42570 |    | Connect |      | Reading from net |                  |
| 446 | unauthenticated user | localhost:42571 |    | Connect |      | Reading from net |                  |
| 447 | unauthenticated user | localhost:42572 |    | Connect |      | Reading from net |                  |
| 448 | unauthenticated user | localhost:42573 |    | Connect |      | Reading from net |                  |
| 449 | unauthenticated user | localhost:42574 |    | Connect |      | Reading from net |                  |
(...)

How to repeat:
You can easily reproduce the attack with:

for a in `seq 1000`; do nc localhost mysql < /dev/null & done ; wait

Adapt the "seq" argument if your max_connections is bigger than 1000.

Suggested fix:
Add a variable called something like max_unauthenticacted_connections that would allow to limit the number of unauthenticated connections.

0 would mean "no limit".

Thanks.

Thank you for a (useful) feature request. I believe, something similar can be achieved by proper (not stateless) firewall usage and settings, but yes, the more levels of seсurity you have against DoS attack, the better.

We recently had the same problem. We're running and ISP with Public MySQL Access too.

You need quite an advanced firewall to intercept this DOS attach (or accidental loop from one of your customers).

the bind-address variable in the MY.CNF file is also only capable of 1 IP address or hostname so you can't solve it with this one.

There is also no a KILL-LIST file or variable in which you can put blacklisted IP Address/hostnames.

How would such a limit help? if the number is reached, new connections will not be possible anyways.
So a better solution would be to limit the number of connections (unauthenticated only probably) from the same IP

(3 years later)

Yes, it's a better fix.

Would it be possible to do?

It's been SIX years since I opened this bug.

3 years since the last comment.

Is MySQL dead ?