I have my wordpress DB hosted on a separate server for security reasons.

Why is it more secure? In general, if you have the DB on the same server then you can only listen for local connections, block the database at the firewall just in case, and even listen only on unix sockets.

How do you know that the attacker traced the server from the front end? Some people just scan for open ports. Its possible to scan the entire IP4 address space provided your ISP does not disconnect you when they start getting a lot of complaints about suspicious behaviour.

You can configure a firewall on the DB server that will only accept incoming connections to the DB port from the IP of the front end server.

IP 6 might help in that it is less likely to be found by scanning IP ranges but I think firewalling or putting the DB on the same server is a better solution.

you could use a vpn but it seems like a firewall limiting access to your web server's IP address, at least for the relevant port(s), would be the simplest solution.

I'm forced to put the DB on another host because I need a high-power instance for the same, which is not available with my front-end host. However, if I put the front on the other host, the network profile is all screwed up (that's a real problem in Asia). The host that I use for the DB has a terrible network. I am trying to get the best of both worlds by using the current set up.

As for port scanning, I doubt if that's how he is figuring this out, because I get his probes within five minutes of changing the IP -- unless the guy's probing every IP on this particular (DB) host. That's unlikely given they probably have about 10,000 IPs in that location. Also note that this same would-be burglar is also using the same IP (his IP) to try to login to my website using the front end. He also tries to request xmlrpc and so on. Anyway, I feel that he's somehow able to 'sniff' out my traffic back to the origin.

For now though, there's been absolutely no probes or attempts since I moved the DB to the same host as the front end and started communicating via private IP, even though the DB instance is open to the world too. (Actually, I run an nginx server on the DB instance too, though it's not used for anything. It's sort of a backup in case the front-end gets attacked and I quickly need to go behind Cloudflare.)

i wouldn't worry too much about how he is finding the IP if you have a simple and effective solution for blocking him.

Heh ... scanning 10k ips is getting trivial these days!

Doesn't your website load slow(er) for having DB away?
If you need higher power instance for DB, you might as well host website on that high power machine, and use DNS to point to your website to your host(ofcourse, assuming that your ISP would allow inbound web traffic).

Is there an issue with always being behind Cloudflare?


For sniffing, the attacker would have to admin level access to web or db server. Unlikely but yet possible!

My guess, would be that he has access to your website in someway, that he is able to read out configs.
Or worse sniffing your home traffic or even worse snooping on your pc.

You will have to narrow down by striking out every possibility.

Heh ... scanning 10k ips is getting trivial these days!

Indeed, you can scan the entire IPv4 space for a port in much less than an hour! There are some public datasets out there that check popular ports monthly.

The hosting provider may have a convention for IP assigning that makes guessing easier, or it could be random Internet noise. If you have any errors/warnings on your front end that may also lend clues to a potential attacker. Easiest way to find that out is turn on logging for php and check logs.

Obviously in MySQL you can allow logins with particular IP/username/password combinations but additionally you could look at something like IP tables and block all traffic to port 3306 minus your hosting IP.

I can't use that high-power machine/host for front-end because they've got a seriously f**ked up network. I prefer my current host's network. But I prefer their machine for heavier tasks like DB. I get over latency issue by putting my php files also on the DB server, and running the webserver on the front-end machine. That way, instead of 50-60 DB queries moving to and fro, there's only one query from Nginx to PHP, and the rest of the processing happens within the core unit.

As for the rest of the possibilities, such as my own computer being compromised or the webserver being compromised, it's rather unlikely, though I've been compromised before when I hosted the front end with a particular host. It must have been some kind of DNS hack at that time, because Google was showing unrecognized pages (product pages -- for diapers etc) from my website, yet there were no such files or pages on the server. This was a couple of years back, and went away when I changed the front-end host.

Btw, I think even if he has access to the front-end server, I guess he has no way of figuring out the public-facing IP address of the core instance, given that the configs refer to the origin by the private IP. Still, I don't think he has that kind of access. The front-end is, for all practical purposes, a simple webserver serving static pages.

As for being behind Cloudflare permanently, I've had mixed results as far as SEO is concerned, with Cloudflare. I'm still tinkering with the option, but so far, the results have not been very encouraging.

. I get over latency issue by putting my php files also on the DB server, and running the webserver on the front-end machine. That way, instead of 50-60 DB queries moving to and fro, there's only one query from Nginx to PHP, and the rest of the processing happens within the core unit.

In that case you can just have the DB listen to 127.0.01 or a unix socket only. That should solve the problem, although I would add a firewall (or rule) anyway. If you know someone it targetting your site best take all precautions you can..

I do not know about MySQL, with with Postgres you can even configure it to authenticate without a password if the database is accessible to a role (db user) with the same name as the OS user.

My guess, would be that he has access to your website in someway, that he is able to read out configs.

Maybe the front end server is compromised.

I'm forced to put the DB on another host because I need a high-power instance for the same, which is not available with my front-end host. However, if I put the front on the other host, the network profile is all screwed up (that's a real problem in Asia). The host that I use for the DB has a terrible network. I am trying to get the best of both worlds by using the current set up.

Earlier you said security reasons?

Personally I would find a provider who can give you both in one instance.

You say Asia, but does it have to be hosted in India? If you cannot find what you need in India (it is an Indian focused site, if its the same one you mentioned in an earlier thread?) there are good VPS providers in SE Asia, maybe even the Middle East.

I am surprised though, most of the big players have Indian data centres.

Earlier you said security reasons?

Initially, I resorted to the split server design for security. Then I realized I could leverage the design to improve performance. And it's stayed that way for several years now. Now, I feel very nervous when someone suggests putting my family jewels (master DB) on a computer that is on the front line.

You say Asia, but does it have to be hosted in India? If you cannot find what you need in India (it is an Indian focused site, if its the same one you mentioned in an earlier thread?) there are good VPS providers in SE Asia, maybe even the Middle East.

I've hosted it in both India and Singapore, and don't find much of a difference, frankly. People say local IP helps in SEO. Not sure of that. Right now, it's in Spore.
But the issue is with having decent latencies to the 4 main mobile networks in India. Most of them will fail in one or two cases (as in, the route will be via France or LA from Singapore). That said, India locations too often give a ping time of 200 ms from a particular mobile network, while that same mobile network will give a ping of 70 to Singapore. So, it's a trade-off. Generally, the best routes are from who the usual suspects like DO, AWS, Linode etc..

Brute force login attacks and xmlrp probes are common ways to infiltrate a WP install. WP does not reveal your db location in its html code. The attacker would need to be able to read your WP config file, which means he may have access to your WP directory, you could check the directory permissions. The WP config file already has adequate file permissions.

If the attacker has access to your wp directory he may have access to other files. Check for new or unknown php files on your server.

@TorontoBoy not in this case. There is a separate front end server, proxying requests to another machine that has both the PHP and databases , so the question is how the attacker is tracing the latter given its IP is not public.

Possibly web server config files are open?

the question is how the attacker is tracing the latter given its IP is not public

I would add a caveat that he's not able to figure out the origin IP when the front end (proxy) communicates with it using private IP only (even if the origin has an external IP), but is able to figure it out when the proxy uses the external IP of the origin to communicate, instead of the private IP.

To me, it looked like he was able to sniff my traffic and see to which IP the proxy server was making persistent connections. I know it's possible to do this inside a LAN. I was wondering if it's possible to do this over the Internet? I was reading upon this subject, and there were some reports that in cases of hosts like Linode, each person doesn't get a VPC, but shares the LAN of the DC. But that again doesn't explain his inability to figure out the private IP (or perhaps he does, but doesn't know how to translate this private IP to a public IP that he can probe from his home or wherever.)

Email?
Is your PHP code sending emails from the back-end server? If so the email headers will expose the server's ip. If the PHP code runs on the DB server and is sending users emails, say to confirm registration, then you would be expose the IP of that server.