Re: Replciation Security

[Rick James]

Several issues; not sure which ones are relevant to your situation. (These are not in optimal order.)

* You might be running the server with --skip-grant-tables. This leaves it totally unprotected.

* Establish a user just for replication:
GRANT REPLICATION SLAVE ON *.* TO repl@'11.22.33.44' IDENTIFIED BY 'secret';
Where the number is the ip address of the slave, and 'secret' is something not easily guessed. Do not use 'root' for replication.

* Change it so that the slave uses the new login (done on slave):
CHANGE MASTER MASTER_USER='repl', MASTER_PASSWORD='secret';
(Check the syntax. You don't need to change any of the other options.)

* Have you verified that the extra statements allegedly injected into the binlog did not actually come from the master? I would guess that the master is also corrupt, and the replication is not the issue.

* Lock down all other logins -- none without passwords, none @'%'. Using ip addresses is possibly safer than host names.

* Be sure some login (usually root) has SUPER and WITH GRANT OPTION. But few if any others should have either of those privileges.

* To be further safe, all of the above should probably be done in a way where no one can get in -- restart the server with --networking=off (check syntax). This way, the only way into the server is by being logged into the machine itself and connecting via 'localhost' (which is not part of '%'). And login via mysql without -h (so that you go in via the socket to localhost).