According to an article by Shadowserver foundation, there were 2.3 million MySQL server instances on port 3306 that were scanned and found accessible worldwide. I was really surprised by the large number and am pretty certain that most people didn't do this on purpose.
First, let’s talk about the reason why having your MySQL (or any port) accessible on the public internet is an attack surface. Any port which is accessible on a public IP address will be scanned, this is a fact. Once a port has been scanned and found that there is a service responding, then the attacks will begin. These will include brute force attacks of username/password combinations, known exploits of OS and applications, various other known Common Vulnerabilities and Exposures, and new hacks are being developed constantly.
Mitigation
Here are the common things people do to attempt to remove the risk.
Add a VPN
You could add a VPN to allow access to the MySQL server to allow you to close the external port on the public IP address.
Pros:
- You got your MySQL port off the public internet and you can do the same for other resources
- You can manage the users who need access centrally
Cons:
- Trading one public IP address and port for another.
- Can be expensive
- Some MySQL databases only have a public endpoint such as an AWS RDS MySQL setup for public access. VPNs can't solve this problem.
- Authenticated VPN users still can see all of the resources tied to the VPN even though they are not authorized to use all of them
- Subnet Collision can render this solution untenable. You can end up with some headaches down the road, especially when you are in the cloud and have multiple VPCs with resources you need to access simultaneously. For example, you have a developer who needs to access MySQL, Redis, RDS Postgres, DynamoDB, etc at the same time, but they are on different VPCs with subnet collision (CIDRs which are the same). Your VPN client will not work in this situation
- You may need public access for some users and resources. In this case you will need to have an access list. Now you are maintaining both a VPN and an allow list. This would be the case for a contractor.
Use IP allow lists
Another option is to manage an IP allow list to prevent port scanners from detecting the port. This can be an additional step to adding a VPN to prevent the VPN port from being detected.
Pros:
- Only requests originating from the list of IP addresses that are allowed will be able to detect the port and connect
Cons:
- These lists are hard to maintain since you will need these security group definitions in many places when you are deployed to multiple VPC and/or Cloud Vendors
- Hard to ensure that the IP address you allowed is static to a user/resource. For example, a cellular hotspot dynamic IP
- User onboarding and offboarding is often incomplete, leaving a potential attack vector.
- As users change locations or their IP address gets reassigned and the authorized user needs to wait for DevOps to update the rules resulting in productivity and time loss.
The above solutions are not Zero Trust Network Architecture where you are giving each user access to only the resources to which they are authorized. Least privileges possible.
Use Remote.It
Remote.It allows you to close the open port while still allowing your people and resources access. When you connect to a resource such as MySQL via Remote.It, you will be given a localhost address and a unique port. You can use this in your development environment connection configuration, database query tools, etc. There is no connecting, disconnecting, and reconnecting when you change locations or your laptop wakes up from sleep. These on demand connections will go idle when you are not actively using it and go active when you do.
- Easy to install
- Simple one line install for most resources
- Works in the cloud (AWS, Azure, Google Cloud) as well as on-prem servers.
- Easy to implement
- Use the organization feature to create tags on your resources
- Create roles to define your member permissions (including filtering by tags)
- Add members to your organization by email address
- Easy to maintain in one central location for all of your resources
- Easy to audit (Logs are available for connections to your resources)
- Can manage this via a Desktop UI or graphQL API
- You can also roll this out gradually without needing to do a big switch.
Is your MySQL server exposed?
Use our tool to see if your MySQL server is exposed.
If your MySQL server is exposed, consider implementing the mitigations listed above. The recommendations can be used together. Remote.It accounts are free for up to 5 endpoints.
We support these popular cloud providers:
AWS
Azure
Google Cloud
Have a self-hosted database? We support that as well with options for Windows and Linux distributions.
Learn more about Remote.It and get started
If you have any questions, comment below or drop us a line at support@remote.it
Latest comments (0)