Free MySQL Port Scanning Tool from Remote.It

February 3, 2024

MySQL Open Port Scanning Tool available

Test if your MySQL database is accessible from the public Internet

Shadowserver foundation recently published scanning results for MySQL server instances on port 3306/TCP. Over 3.6 million MySQL servers were accessible worldwide. For almost all of these databases, there is no use case for the general public to access or even know these servers exist. Shadowserver works with national governments, network providers, enterprises, financial and academic institutions, law enforcement agencies, and others, to reveal security vulnerabilities, expose malicious activity and help remediate victims.

Try our MySQL Open Port Scanner

In May 2022, they scanned for accessible MySQL server instances on port 3306TCP. Port 3306 is the default MySQL port. The scan initiated a MySQL Server Greeting without performing any intrusive checks to discover the level of access to any databases.  The result was 3.6 million accessible MySQL servers worldwide with 2.3 million IPv4 addresses and 1.3 million IPv6 devices responding to the query.

Accessible MySQL servers by unique IPv4, Copyright Shadowserver Foundation

Why do users have open ports?

There are many valid reasons for having open IP ports such as developers requiring access to resources within a private IP address space. The resources could be on-premise within the company or hosted in a public cloud location such as Amazon AWS, Google Cloud Platform, or Microsoft Azure. Additionally, SaaS applications like HR, marketing, analytics, and other tools may require connections to private resources.

What risks do open ports introduce?

Open ports become dangerous when legitimate services are exploited through security vulnerabilities or malicious services are introduced to a system via malware or social engineering, cybercriminals can use these services in conjunction with open ports to gain unauthorized access to sensitive data. See our MySQL open port honeypot results.

What are common mitigations for open ports?

The two most common mitigation steps to protect companies for open ports are: allowed lists and VPNs. Enforcing IP allowed lists ensure that only known and authorized IP addresses can connect via the open port. This removes the risk of malicious scanners and bot attempting to find and take advantage of known security exploits. VPNs can also be used to add an extra authentication layer.  VPNs will block unauthorized access via the open port. Allowed lists and VPNs can be used together.

The challenge for open port mitigations such as allowed list and VPNs is the ongoing effort to maintain the lists and scale resources for more users. Users would need to provide the IP address of all new locations to the IT/DevOps department before connecting.  VPNs either require additional hardware scaling or purchasing expensive licenses for hosted solutions.

Get started with a free Remote.It account

Learn how to deploy Remote.It in an:

Move away from legacy networks - enjoy the freedom of connectivity as code

By deploying a single line of code within their corporate cloud infrastructure, companies are able to eliminate the need to use discoverable Public IP addresses for access that in turn eliminates the attack surface.

“Cloud resources can be in different regions or even within different cloud providers and Remote.It makes them all available simultaneously. No connecting, unconnecting, and reconnecting as is required with legacy VPN type solutions. And because our solution operates at layer 4, our connections are peer to peer, so unlike CASB (CloudAccess Security Broker)” type solutions – sensitive corporate data businesses’ traffic isn’t routing through us”, said Ryo Koyama, CEO of Remote.It.

Cloud native developers need to be freed from the limitations of legacy networks. In addition to providing cloud access to resources with no public IP address, development environments are becoming too large and too dispersed to easily and predictably replicate on local machines. Deploying Remote.It means that those resources, when they are in production, staging, or development, are directly available as if they were running directly on the developers local machine. This way of working is not only faster, it’s easier and safer to manage.

Related Blogs