Overview
Database management systems such as MySQL, PostgreSQL, MongoDB, and Redis listen on well-known TCP ports by default. When those ports are reachable from the public internet — or from untrusted internal network segments — attackers can interact directly with the database service without first traversing any application-layer security control. Depending on the database's own authentication and authorisation configuration, this exposure ranges from credential brute-forcing to completely unauthenticated data access.
Redis in particular shipped for years with no authentication enabled by default. Numerous MongoDB deployments were publicly exposed without credentials during 2017–2018, resulting in mass data theft and ransom campaigns. These incidents underscore that network-layer exposure is a precondition that dramatically lowers the bar for exploitation of any subsequent weakness in the database's own access controls.
How it works
Automated internet scanners continuously probe the IPv4 and IPv6 address space for open ports. Once a database port responds, attackers proceed through a predictable attack chain:
- Service fingerprinting: The initial TCP handshake and server banner (e.g., MySQL's initial handshake packet, Redis's inline
PINGresponse) confirm the database type and version, enabling targeted exploitation. - Authentication bypass or brute-force: Default credentials (
rootwith empty password on MySQL, no authentication on Redis <6.0, anonymous access on older MongoDB) are tried first. Credential-stuffing lists derived from prior breaches extend this further. - Unauthenticated access (Redis / legacy MongoDB): Redis prior to version 6.0 has no authentication by default. An attacker can issue commands such as
CONFIG SET dirandCONFIG SET dbfilenamefollowed bySAVEto write arbitrary files on the server filesystem, commonly used to plant SSH authorized_keys or cron jobs for remote code execution. - Data exfiltration: Once authenticated (or when authentication is absent), full dataset enumeration and extraction is trivial using standard client tools or scripted queries.
- Ransomware / data destruction: Automated tools have been widely deployed to drop databases and leave ransom notes, exploiting open MongoDB and Redis instances at scale.
- Lateral movement: A compromised database host often has credentials or network access to additional internal systems, enabling further pivot.
Common root causes include: cloud security group or firewall rules that apply 0.0.0.0/0 ingress to database ports; misconfigured Docker or Kubernetes service exposures that bind database containers to all network interfaces; and failure to apply the principle of least privilege in network architecture (i.e., no database subnet / DMZ separation).
Business impact
Exploitation of an exposed database port can result in complete compromise of all data stored in that database. Specific consequences include:
- Data breach: Personally identifiable information (PII), payment card data, health records, authentication credentials, and proprietary business data can be exfiltrated in minutes.
- Regulatory penalties: Exposure of personal data violates GDPR Article 32 (appropriate technical measures), HIPAA Security Rule §164.312, PCI DSS Requirement 1 (firewall controls), and similar frameworks, carrying potential fines and mandatory breach notifications.
- Data destruction and ransomware: Automated attack campaigns routinely delete database contents and demand payment for their return. Recovery without backups may be impossible.
- Remote code execution: Redis misconfigurations enabling filesystem writes have been extensively exploited to achieve OS-level RCE, escalating impact far beyond the database itself.
- Reputational damage: Public disclosure of a breach attributable to an openly accessible database is particularly damaging, as it signals fundamental security negligence.
How to fix it
- Block database ports at the network perimeter: Configure firewall rules, cloud security groups (AWS Security Groups, Azure NSGs, GCP Firewall Rules), or host-based firewall (iptables/nftables/ufw) to deny all inbound connections to database ports from any source other than explicitly trusted application server IP addresses or CIDR ranges. Never allow
0.0.0.0/0ingress on database ports. - Bind database services to localhost or private interfaces only: Set
bind-address = 127.0.0.1in MySQL/MariaDBmy.cnf;listen_addresses = 'localhost'in PostgreSQLpostgresql.conf;bind 127.0.0.1in Redisredis.conf; andnet.bindIp: 127.0.0.1in MongoDBmongod.confunless cross-host replication is required. - Enable and enforce strong authentication: Use a strong
requirepassin Redis 6+ (or enable ACL-based authentication); ensure PostgreSQL usesscram-sha-256authentication inpg_hba.conf; disable MySQL anonymous accounts and enforce password policy; enable MongoDB authentication (security.authorization: enabled). - Place databases in a dedicated private subnet: Network architecture should ensure database nodes reside in a subnet/VPC with no direct route from the internet. Application servers communicate via private IPs only.
- Use encrypted tunnels for remote administration: All DBA access should occur through an SSH tunnel, VPN, or bastion host — never by opening the database port to the internet.
- Upgrade to current versions: Ensure all database software is on a supported, patched release to benefit from security improvements (e.g., Redis 6.0+ mandatory authentication, MongoDB 4.0+ TLS enforcement).
- Enable TLS/SSL for client connections: Configure databases to require encrypted connections to prevent credential interception on any network path that is accessible.
- Audit periodically: Regularly scan your own infrastructure for inadvertently exposed database ports. Sensagraph continuously detects exposed database service ports across monitored assets.