Database Scanner — Find Exposed MongoDB, Elasticsearch, Redis & MySQL

Discover exposed databases on the internet — MongoDB, Elasticsearch, Redis, MySQL, PostgreSQL, and more. Check if your databases are publicly accessible and learn how to secure them.

The Exposed Database Problem

Exposed databases are one of the most critical and common security issues on the internet. Every week, news breaks about another data breach caused by a misconfigured database left open to the internet without authentication.

Many databases ship with authentication disabled by default or bind to all interfaces (0.0.0.0) out of the box. When deployed on cloud instances with public IPs, they become instantly discoverable by internet scanners.

Zondex continuously scans the internet and indexes these exposed database services, making it possible to identify and secure vulnerable databases before attackers find them.

Commonly Exposed Database Types

DatabaseDefault PortRisk LevelZondex Query
MongoDB27017Criticalport:27017 product:MongoDB
Elasticsearch9200Criticalport:9200 product:Elasticsearch
Redis6379Criticalport:6379 product:Redis
MySQL3306Highport:3306 product:MySQL
PostgreSQL5432Highport:5432 product:PostgreSQL
Memcached11211Highport:11211 product:Memcached
CouchDB5984Highport:5984 product:CouchDB
Cassandra9042Mediumport:9042 product:Cassandra

Exposed MongoDB Databases

MongoDB is one of the most commonly exposed databases on the internet. It ships with authentication disabled by default (prior to v6.0) and binds to all interfaces. Thousands of MongoDB instances containing terabytes of data have been found exposed, leading to major data breaches and ransomware attacks targeting unprotected databases.

Default Port
27017
How to SecureEnable authentication with mongod --auth, bind to 127.0.0.1 in mongod.conf, enable TLS, and use firewall rules to restrict access to port 27017.

Exposed Elasticsearch Databases

Elasticsearch clusters are frequently found exposed on port 9200 with no authentication. By default, Elasticsearch has no built-in authentication (X-Pack Security was optional until v8.0). Exposed instances often contain log data, customer records, and PII from web applications.

Default Port
9200
How to SecureEnable X-Pack Security (built-in since v8.0), configure TLS, set network.host to a private IP, use Kibana with authentication, and restrict port 9200/9300 via firewall.

Exposed Redis Databases

Redis, an in-memory data store, is designed to be accessed from trusted environments and has no authentication by default. Exposed Redis instances can lead to remote code execution through the CONFIG SET and SLAVEOF commands, making this one of the most dangerous exposure types.

Default Port
6379
How to SecureSet a strong password with requirepass in redis.conf, bind to 127.0.0.1, disable dangerous commands (CONFIG, FLUSHALL, etc.), enable TLS, and never expose port 6379 to the internet.

Exposed MySQL Databases

MySQL instances exposed on port 3306 are commonly found in the wild, though MySQL does require authentication by default. The risk comes from weak passwords, known exploits in older versions, and potential brute-force attacks. Exposed MySQL servers often indicate broader infrastructure security issues.

Default Port
3306
How to SecureBind to 127.0.0.1 in my.cnf, use strong passwords, disable remote root access, keep MySQL updated, enable TLS with require_secure_transport, and use firewall rules.

Exposed PostgreSQL Databases

PostgreSQL requires authentication but can be misconfigured with pg_hba.conf allowing trust authentication from any host. Exposed PostgreSQL instances on port 5432 are less common than MongoDB or Redis but still represent a significant security risk.

Default Port
5432
How to SecureReview pg_hba.conf to ensure no trust or peer authentication from remote hosts, bind to localhost, use scram-sha-256 authentication, enable SSL, and restrict port 5432 access.

Exposed Memcached Databases

Memcached has no authentication mechanism at all. Exposed instances can leak cached application data and have been exploited for massive DDoS amplification attacks (the memcrashed attack of 2018 generated 1.7 Tbps attacks). Never expose Memcached to the internet.

Default Port
11211
How to SecureBind to 127.0.0.1 with -l 127.0.0.1, disable UDP with -U 0 (prevents DDoS amplification), use firewall rules, and consider SASL authentication if remote access is necessary.

Exposed CouchDB Databases

CouchDB instances on port 5984 expose a REST API that, when unauthenticated, allows full read/write access to all databases. The Fauxton web UI on the same port provides a visual interface to browse and modify data.

Default Port
5984
How to SecureCreate admin users (CouchDB runs in "Admin Party" mode by default), bind to 127.0.0.1, enable HTTPS, and restrict access through firewall rules.

Exposed Cassandra Databases

Apache Cassandra CQL interface on port 9042 does not require authentication by default. While Cassandra is typically used in enterprise environments with proper networking, misconfigured instances can expose large-scale distributed databases.

Default Port
9042
How to SecureEnable authentication with authenticator: PasswordAuthenticator in cassandra.yaml, configure SSL, use rpc_address to bind to specific interfaces, and restrict port 9042.

How to Use Zondex as a Database Scanner

Zondex scans common database ports across the entire internet and indexes the banners they return. Use these queries to find exposed databases within your organization's IP ranges:

Database Security Best Practices

Enable Authentication

Always enable authentication, even in dev. Use strong passwords and RBAC. MongoDB, Redis, and Elasticsearch ship with auth disabled by default.

Bind to Localhost

Configure databases to listen on 127.0.0.1 or a private interface only. Never bind to 0.0.0.0 unless properly firewalled.

Use Firewall Rules

Configure iptables, security groups (AWS), or NSGs (Azure) to restrict database port access to trusted IPs only.

Enable TLS Encryption

Encrypt connections with TLS/SSL to prevent credentials and data from being intercepted.

Monitor & Audit

Regularly scan your own infrastructure with Zondex to verify databases aren't accidentally exposed. Set alerts for new open ports.

Use VPN / SSH Tunnels

For remote administration, use SSH tunnels or VPN connections instead of exposing database ports directly.

Frequently Asked Questions

What is a database scanner?
A database scanner is a tool that discovers database services (like MongoDB, Elasticsearch, Redis, MySQL) exposed on the internet. Zondex acts as a passive database scanner by continuously indexing open database ports across the entire IPv4 space, letting you search for exposed instances instantly.
Why are databases exposed on the internet?
Most database exposures happen because: (1) databases ship with authentication disabled by default, (2) developers bind to 0.0.0.0 instead of 127.0.0.1, (3) cloud instances have public IPs with no firewall rules, and (4) Docker containers map ports to all interfaces. Many developers don't realize their database is publicly accessible.
How can I check if my database is exposed?
Search your public IP on Zondex using host:YOUR_IP and look for database ports (27017, 9200, 6379, 3306, 5432). You can also search your organization: org:"Your Company" port:27017,9200,6379,3306,5432 to find all exposed database instances.
Is it legal to scan for exposed databases?
Searching for publicly available scan data on platforms like Zondex is legal. Accessing data within an exposed database without authorization is illegal, even if no authentication is required. Always use database scanners to secure your own infrastructure, not to access others' data.
What is the most commonly exposed database?
MongoDB and Elasticsearch are the most commonly exposed databases on the internet, primarily because older versions shipped with authentication disabled by default. Redis is also frequently exposed and is particularly dangerous because it can be exploited for remote code execution.
How do I secure my database from internet exposure?
Follow these steps: (1) Enable authentication with strong passwords, (2) Bind to 127.0.0.1 or private IPs only, (3) Configure firewall rules to block database ports from the internet, (4) Enable TLS encryption, (5) Use VPN or SSH tunnels for remote access, (6) Regularly scan your infrastructure with Zondex to verify you're not exposed.

Find Exposed Databases — Free

Use Zondex to check if your MongoDB, Elasticsearch, Redis, or MySQL instances are publicly accessible.