MySQL database (non-SSL) connections secured via origin/destination IPs, how unsafe are they?

Question

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.

Answer 1

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.