A client of mine has recently moved his web site to another ISP. The site is, commercially seen, a distribution portal deploying shopware.

But now the client is insecure whether the database (mysql) migration was correct in the sense that he fears that processes on the "new" server access the database on the "old" VPS (the "old" server is still running and should be as long as the issue is not sorted out).

My question is:

How can I securely verify that the processes on the new server DO NOT access the database on the "old" VPS?

One of my first ideas was to use the mysql status command for this, but I think this is useless for my purpose, since it only shows on which host the database is located to which the db server is connected, not a client (script). Am I right?

I am reluctant to just shutdown the "old" VPS, but my current idea is to use iptables to close ALL ports on the "old" server apart from 22 to not lock me out, execute operations using shopware on the new site which should result in db queries and check the result on the web page/frontend resp. the mysql error log on the "new" VPS.

Does this make sense or is there a better, more general, more reliable approach (I cannot exclude that, apart from the shop, other processes rely on the database!)?

Couple of thoughts:

1. By default, a mysql installation will only access databases on the localhost.
2. Stop the mysql server on the old server, then see if queries still work. If so, then they're accessing the new server.
3. Change something on the old server -- maybe add a table -- only...see if the new server query sees the change.

No 3 is probably the least intrusive, but a short shutdown as in #2 should be OK, too. You don't need to shut down the entire server, just stop the mysqld process.

That would seem strange to me...
That would mean that the mysql port is open from outside and the new server's IP is authorized on the old server. Usually people have to change config files to do that on purpose, so doing it by accident...

Just change mysql users' passwords on either server.

1 members found this post helpful.

There has to ba a configured connection set up somewhere - just look at the configuration and see where it is opening the connection to, should not be difficult if you have access.

I agree with lougavulin though, you have to configure and explicitly allow network access to mysql, so having it happen by accident or coincidence would seem a bit unusual. But the OP does not say whether the client was connecting to mysql via network before the move either. If so, it "might" still connect after the move if it is badly configured or if the new host has the same name as the old.

If the listening server has grants on *.* from *@* then it needs to be shut down anyway!

1 members found this post helpful.

Hello together,

thanks a lot for all Your replies. There are still questions open:

@scasey:

I think behind Your thoughts is the notion that the MySQL server on the new machine could theoretically be configured that it, by default, could connect to a database outside the local host, i.e., to the old server. But, as the other guys imply, this is quite improbable.

My consideration was different. E.g., in Perl, I could do the following:

and the script will connect to the mysql database <dbname> on the server with IP 178.xxx.yyy.zzz, which, from my point of view, can be the local host or a remote machine.

If such a script is migrated to the new server with a different IP address, the queries will access the "old" datasbase, not the "new" one. Am I right?

@scasey:

Your second suggestion would be suitable for testing this (provided one is able to execute a connect statement like the above one; in our case the most sensible way to do is to use the shop installation for this and try to trigger queries from the web site by making a new order, e.g.).

@lougavulin:
@lougavulin:

What do You mean by "the new server's IP is authorized on the old server"? Where would this be configured for mysql?

I think Your method of changing the db user password is effective to test the above depicted case.

@astrogeek:

Once again: where can I check this configuration?

How? The two machines can't have the same IP address. That connection will connect to the database running on the server with that IP address...or not, if it's the old machine and the old machine's database is not configured to accept remote connections.

Yes, again if the old data base is configure to allow it. If it's not, you'd get an error. Add an or die to that statement to get an error logged.


OK



The mysql configuration file is /etc/my.cnf by default. It should be well commented...somehow mine got all its comments removed.

The authorization lougavulin and astrogeek are talking about is in the database...I'm not sure where, because I use phpmyadmin to administer my databases. All my users are only valid for localhost.

Actually the client configuration I was talking about would be in the application itself, just as phpmyadmin has a configuration file that tells it where to connect. Just login to the DB client machine, that is the application server, and look at its configuration - where does it think it is connecting to?

On the mysql DB server you have to enable networking, usually in the init scripts, where ever the mysql server gets started. Additionally, you have to issue GRANTs to allow connections from a remote host just as for a local user. Something like this...

The only way it would respond to an external connection is if it were started with networking enabled AND if the grant table had a match for the user, host and password! That is why it almost could not happen by accident!

BUT - if the new client host has the same name as the old one, as well as configured with same username and password, it might just connect! Alternatively, if the DB server had wide open grants, i.e GRANT ALL ON *.* TO *@* plus password, then it would allow connections from just about anything - very bad idea!

1 members found this post helpful.

scasey and astrogeek have answered many points.

So, just to clarify, the idea to change the mysql users' password on one server is for :
1- as astrogeek said about GRANT, this should "disabled" the GRANT if it is not too wide.
2- say you change passwords from the old sever then process accessing datas should get a logon error if it tries to connect on the old server.

1 members found this post helpful.