CODEWITHSUNDEEP
mysqlamazon-web-servicesamazon-ec2rds
Chanon
Chanon

Reputation: 476

ATTACK ON AWS RDS MySQL .static.midphase.com resembles IPv4-address itself

I'm running EC2 with MySQL RDS to serve dynamic websites' content. The server was down due to 'too many connection' error on RDS database.

As it was urgent, I restart database server straight away and the problem gone. However, I'm unable to see what queries produce those connection (as I didn't run SHOW PROCESS LISTS before reboot RDS).

CloudWatch show 250+ connections during period of issue which is obviously huge distinction from normal operating on other days.

I try to address the issue by see log in RDS, but there is quite a minimal message there.

The error message

2014-05-03 06:10:08 3628 [Warning] IP address '173.244.206.19' has been resolved to the host name '173.244.206.19.static.midphase.com', which resembles IPv4-address itself.

From above, 173.244.206.19 is not in our IP list both public and private. (but connection open to 0.0.0.0 secured with password which I'm going to limit IP remote in security group soon)

Questions

  1. Is 173.244.206.19.static.midphase.com is something to do with RDS by default. I think this is obviously an attack sign but just would like to confirm.
  2. What does 'resembles IPv4-address itself' mean? As this is RDS database server only, why server does need to resolve DNS?
  3. Are there any way to digging into this for further detail (e.g. to see specific query).
  4. I'm going to prevent this by only limit the IP access along with CloudWatch alarm setting for 10+ connections. Anything else I should do.

Thank you for reading through this guys. I'm the only developer in company start-up which take care for all front-end/backend/application/network. Therefore, apology if there are dummy questions out here.

However, your help would be really appreciated and will save a bit of my life writing the report.

Upvotes: 2

Views: 3664

Answers (1)

Sébastien Stormacq
Sébastien Stormacq

Reputation: 14905

You are maybe the target of a DDOS attack or a brute-force password discovery attempt. I would report this to AWS support - as they can help to mitigate the effect of the attack.

As a best practice, we do not recommend to use 0.0.0.0/0 as source IP address for incoming connection rule in Security Group.
Try to restrict which IP addresses are authorised to connect to your database. If you are accessing from on prem network, specify only your on-prem address range. If you're accessing your database from an app server installed on EC2, use the ID of the App Server Security Group (sg-xxxx) as source authorised to connect to your database.

Upvotes: 2

Related Questions