4

We have a web site hosted on a shared server. The hosting company's MySQL servers are hosted on a different server.

We collect certain kinds of requests through a web form, and write them to a database. Every 10 minutes, cron runs a php script that

  • queries a view in the database (no user-supplied or program-supplied parameters),
  • emails new requests to us, and
  • writes the keys for new requests to another table, effectively removing those rows from the view.

That's the only process running under cron, and cron runs just that one script.

All php database access is through PDO. Inserts use PDO's bindParam.

A single php file contains the connection information for the MySQL server. It's stored outside the web root, I'm the owner, and its permissions are read/write for me alone with no other permissions at all.

Yesterday, I got this error message emailed from cron.

SQLSTATE[HY000] [1130] Host 'somedomain.org' is not allowed to connect to this MySQL server

So far, this is a one-time error. The rest of the time, the php script works as designed.

Neither that domain nor its IP address appear in the web server's log files or in a database dump.

Am I correct in interpreting this as an attempt to crack our server?

Is this configuration good enough to keep our data safe unless my own credentials are compromised?

Later...

The web site for 'somedomain.org' is hosted on the same server our web site's on. If they'd simply made a typo in connecting to their own database, any error message I might see shouldn't have come from cron. This error, coming from cron, seems to be telling me that somehow they're trying to use their credentials, but running my script. Is that right?

Still later...

One of my Google alerts tells me that a content aggregator, 'yetanotherdomain.com' has started scraping data from our web pages. This domain, 'yetanotherdomain.com' is not hosted on the same server our web site's on. But administrative and technical contacts for both 'somedomain.org' and 'yetanotherdomain.com' are registered to the same phone number in the USA.

I looked up the IP address of 'yetanotherdomain.com' using host. Following up with whois <ip address> gives me this output (snipped).

network:Street-Address:N/A
network:City:Kiev
network:State:OT
network:Postal-Code:04209
network:Country-Code:UKR
| improve this question | |
  • 1
    Could it be possible that the script is configured incorrectly and using the hostname "somehost.org" rather than your domain? That sounds like it may be the cause. – Andy Smith Aug 6 '12 at 13:24
  • @AndySmith: Makes sense, but no, it's using the right hostname. (I checked.) If the hostname were wrong, I'd get that error every time. I've only seen that error once, though. The rest of the time it's worked fine. – Mike Sherrill 'Cat Recall' Aug 6 '12 at 13:32
  • That's a little unusual, but as you're on shared hosting I suppose a lot of things could be happening. Does your script explicitly use the correct IP/hostname or have you just observed that it uses the correct ones? – Andy Smith Aug 6 '12 at 14:02
  • @AndySmith: It explicitly uses the correct hostname. In testing and in production, it connects to the right host, emails the right people, and inserts the right rows. – Mike Sherrill 'Cat Recall' Aug 6 '12 at 14:18
3

My first guess would not be a hacking attempt, but rather a transient glitch in your shared hosting's DNS or something similar. On shared hosting, something like this could easily happen for a brief period.

Update (8/7): If you are concerned that you might be under a hacking attack, my suggestion would be: rather than expending a lot of energy trying to confirm whether you are in fact under attack or not; rather than expending a lot of energy trying to identify the perpetrator; instead, I suggest that you focus on making sure your system is secure against attack and can resist attacks.

Take this as a good opportunity to review your security practices and the configuration of your systems to ensure that you are in good shape. If you are under attack, this will help protect yourself -- and even if you are not under attack, you get good protection against other kinds of attacks. In either case, you will have the peace of mind of knowing you've done all you can to lock down your systems.

| improve this answer | |
  • I could buy that explanation. On the other hand, see my latest edit to my question, "Still later...". – Mike Sherrill 'Cat Recall' Aug 7 '12 at 11:46
  • On a shared host, it makes sense to report it to the shared host's tech support, too. – Mike Sherrill 'Cat Recall' Aug 8 '12 at 11:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.