The database is alive, but the ports are talking too much.

Nmap is the fastest way to know exactly what they’re saying—and who they’re saying it to. When databases are exposed, attackers map them before you can blink. By scanning with Nmap, you see the same surface they see, down to the open TCP ports, service banners, and unexpected endpoints. This is the first step in securing access.

Run a scan against the target host and restrict it to database-related ports:

nmap -p 1433,1521,3306,5432,27017 <target-ip>

This pinpoints whether Microsoft SQL Server, Oracle, MySQL, PostgreSQL, or MongoDB is reachable. Pair this with service and version detection:

nmap -sV -p 1433,1521,3306,5432,27017 <target-ip>

Now you have exact software versions. You can audit them, cut off unneeded services, and lock down firewall rules.

For secure access, the goal is to present zero unnecessary entry points. Limit database listening addresses to internal subnets. Require VPN or bastion hosts for any query access. Disable weak authentication methods. Use TLS for all transmissions, confirmed by checking port state and certificate details with Nmap’s --script ssl-cert option.

Advanced Nmap scripts, like mysql-info or pgsql-brute, can identify misconfigurations before they appear in a CVE feed. Aggressive timing (-T4) accelerates scans but should respect production limits. Combine host discovery (-sn) with CIDR blocks to find forgotten dev or staging databases running in corners of your network.

Securing database access is not a one-time sweep—it’s a cycle. Scheduled Nmap scans, tied to deployment pipelines, ensure no drift into unsafe exposure. The fewer ports open to the world, the less surface an attacker can hit.

You can see how continuous scanning and lockdown are supposed to work. Use Nmap to reveal the truth. Then try hoop.dev to experience secure, controlled access in minutes—see it live now.