I am testing an Amazon RDS MySQL solution: the database is provided by Amazon RDS but the application logic (php scripts) that accesses the data is hosted in another, different (non-amazon) server.

Suppose that for some reason I can't use MySQL SSL connections and I rely only on the security provided by the origin/destination policies you can set on Amazon VPC: I can say that the MySQL instance can accept traffic ONLY from a specific IP (the IP of my Web server) and can send traffic ONLY to a specific IP (again, the IP of my Web server).

How unsafe is this solution? I know the question seems too vague, but there are some specific details I would like to clarify; let's try to see what can happen:

1) Data (including MySQL credentials) are sent in clear over the Internet, so if it is sensible data, it might be seen by an external party. How easy is this attack? The fact we are using IP and not domain names in the policy makes a man-in-the-middle attack more difficult to execute?

2) Assume an attacker manages to steal the MySQL credentials using 1), how easy executing arbitrary queries on the MySQL instance would be? The attacker has to pretend to have my webserver's IP, operation that should be harder in "receiving mode" than in "sending mode". So I guess there are two different categories of queries we should consider separately:

A: Arbitrary SELECT queries (in general, queries that ask for some kind of data back)

B: Arbitrary DELETE, UPDATE, INSERT, ... (in general, queries that doesn't need an answer)

I would say queries B are easier to execute but this might depend on other factors such as the specific protocol used by MySQL.

  • docs.aws.amazon.com/AmazonRDS/latest/UserGuide/… Why aren't you using SSL? May 10 '16 at 16:05
  • I know how to use SSL, my question starts with: "Suppose that for some reason I can't use MySQL SSL connections". On one side, I would like to understand what is the risk for the pure sake of curiosity, on the other side, sometime you might be in a situation where you CAN'T use it (for example you HAVE to use a third-party application which doesn't provide SSL connections and you cannot modify it).
    – Eugenio
    May 10 '16 at 16:16
  • Still too little information. Is the network on the non amazon host a secured private network, or a generic VM network? May 10 '16 at 16:26
  • It's a web space provided by an hosting provider, I don't have information about it now. Consider the worst case scenario.
    – Eugenio
    May 10 '16 at 16:51

You are correct to be concerned about the scenarios you presented:

  1. If a MITM attack occurs, it cannot be thwarted unless you use SSL. The IP filter will not help because the attack is already "in the middle" of the connection, so all traffic will pass through it in plain text. Once the user/pass is grabbed, the attacker can do whatever those credentials allow. The attacker could even spoof the IP and hijack the connection without allowing traffic back to the original IP, if they choose to.
  2. For attacks that are not MITM, the IP filter helps quite a bit, because even IP spoofing would only allow messages to be sent, but not received, and even then they would still need to first figure out the credentials. If they did somehow figure out the credentials they could spoof their originating IP and send commands such as delete, update, insert, etc, but it would be pretty difficult to know whether or not it was having any effect, so it would be pointless for them to try. (Like throwing rocks into a lake and wondering if you are hitting any fish on the way down.)

Your best bet is to use SSL or at least move the application and DB into the same network. If you absolutely can't do that, MITM is the most realistic attack you should worry about, but even those are pretty rare, in comparison to other types of attacks that would be attempted. You're probably more likely to have a developer accidentally leak the credentials than to have a MITM performed against you.

  • Note that "move the application and DB into the same network" can be accomplished with a vpn too.
    – TTT
    May 10 '16 at 17:03

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.