Exposed Database on the Internet: Emergency Remediation for Redis, MongoDB, and Elasticsearch
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Database exposure incidents follow a predictable pattern. An engineer deploys a database on a cloud VM for testing, assigns it a public IP, does not configure authentication 'for now,' and then either forgets about it or moves on. Automated scanners find it within hours. The exposure window compounds over days or weeks before anyone notices. By the time the exposure is discovered — through a Shodan alert, a ransom note replacing the database contents, or a security audit — the data has been scraped.
The immediate response has two tracks: network containment (close the access) and forensic assessment (determine what was accessed). Both must happen simultaneously, with containment prioritized because every minute of continued exposure extends the potential damage.
Immediate containment: close access within 15 minutes
Every minute the database remains accessible extends the exposure window and increases the probability that automated bots have already scraped or deleted data. Containment requires no deep forensic understanding of the incident — it requires only a firewall rule change or security group update that blocks the database port from external IPs. The two steps in this section cover how to block access at the network level and how to preserve logs before any configuration changes are made, since log evidence is the only way to reconstruct what occurred during the exposure window.
Block the database port at the network level immediately
The fastest path to containment: block the database port at the firewall or security group level. In AWS: Security Groups > select the group applied to the database instance or host > Inbound rules > delete any rule allowing the database port from 0.0.0.0/0 or ::/0. In GCP: VPC Network > Firewall > delete the rule allowing the database port from all sources (0.0.0.0/0). In Azure: Network Security Group > Inbound security rules > delete or deny the rule. For on-premises or dedicated hosts: iptables -I INPUT 1 -p tcp --dport PORT -j DROP (INSERT at position 1 ensures it takes effect before any ACCEPT rules). Verify from an external IP (not your office network, which may have a separate firewall path) that the port is no longer reachable. The application will break — this is acceptable and expected. Restoring application connectivity to the database happens through a private network path after containment.
Preserve logs before any database restart or modification
Before changing any database configuration or restarting the service: copy the current log files to a separate storage location. MongoDB logs: cp -r /var/log/mongodb/ /tmp/forensic-mongodb-logs-$(date +%Y%m%d)/. Redis logs: cp /var/log/redis/redis-server.log /tmp/forensic-redis-log-$(date +%Y%m%d).txt. Elasticsearch logs: cp -r /var/log/elasticsearch/ /tmp/forensic-elasticsearch-logs-$(date +%Y%m%d)/. Also take a snapshot of current database state: in MongoDB, run db.adminCommand({listDatabases: 1}) and for each database, db.getCollectionNames() to document what collections exist (or existed before any ransom-deletion). This snapshot is the baseline for the forensic assessment. If ransom-deletion has already occurred: the ransom note collection is itself evidence — photograph it and document its contents before removing it.
Hardened redeployment: reconnect the application securely
After blocking external access and copying logs for forensic review, the next phase is reconnecting the application through a private network path with authentication enabled. Hardened redeployment means the database never again binds to a public IP without authentication — it moves to a private subnet or private IP binding, and all application connections go through a private network path instead of the public internet. The two steps below cover moving to private networking and then verifying that authentication is working before declaring remediation complete.
Move to private networking before re-enabling any access
The goal of hardened redeployment is for no database port traffic to ever traverse the public internet. In AWS: place the database in a private subnet with a route table that has no Internet Gateway route. Configure a Security Group that allows inbound on the database port from the Security Group ID of the application servers (not from an IP range, and never from 0.0.0.0/0). The application servers communicate with the database via the private IP within the VPC. For self-hosted environments: place the database on a VLAN with no internet routing, with a firewall rule permitting connections only from the application server IP range. If the application is in a different network segment or data center: use a site-to-site VPN or private peering connection rather than routing database traffic over the public internet.
Enforce authentication and test the application before declaring remediation complete
After enabling authentication (see database-specific FAQ entries): update all application connection strings to include the database credentials. Store credentials in your secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) rather than in application configuration files or environment variables in plaintext. Verify the application connects successfully to the database via the new private network path with authentication. Run the application's integration tests or a manual smoke test of key functionality. Monitor the database logs for any failed authentication attempts — failed attempts from external IPs after the network block was applied indicate a misconfigured network path that should be investigated. Document the incident: exposure window, data types affected, access log findings, containment actions, and hardening steps taken.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Database exposures are fast to remediate (a firewall rule takes 2 minutes) and slow to fully assess (determining exactly what was accessed during the exposure window takes days). Prioritize containment — block the port, then assess. The hardening path is straightforward: private networking eliminates the exposure class entirely, and authentication is a mandatory layer even on private networks. The prevention controls that matter most are infrastructure-as-code security review (automated checks flag 0.0.0.0/0 database access rules before they are deployed) and CSPM tooling that continuously monitors for publicly accessible databases. Both detect this configuration class before it causes an incident rather than after.
Frequently asked questions
My database is exposed to the internet with no authentication. What do I do first?
Immediate containment sequence — execute in this order within the first 15 minutes: (1) Block public access via firewall rule: in AWS, add a Security Group inbound rule to deny all traffic on the database port (27017 for MongoDB, 6379 for Redis, 9200 for Elasticsearch) from 0.0.0.0/0. In Google Cloud, remove the Firewall rule that allows the port from all sources. In Azure, update the Network Security Group to deny inbound traffic on the database port. For bare-metal or self-hosted: iptables -A INPUT -p tcp --dport 27017 -j DROP (replace port with your database's port). (2) Verify the block: from an external connection (your phone on mobile data, not your office network), confirm the port is no longer reachable. (3) Do not restart or modify the database yet — you need the current access logs for forensic review. (4) Enable authentication on the database (see the database-specific FAQ entries). Containment first, then forensics, then hardening.
How do I enable authentication on a running MongoDB instance that has none?
MongoDB authentication enablement without data loss: (1) Create the admin user BEFORE enabling authentication (if you enable authentication before creating the admin user, you will be locked out). In the mongo shell: use admin; db.createUser({user: 'adminuser', pwd: 'STRONG-RANDOM-PASSWORD', roles: [{role: 'userAdminAnyDatabase', db: 'admin'}, 'readWriteAnyDatabase']}). (2) Create application-specific users with minimum required permissions: db.createUser({user: 'appuser', pwd: 'APP-PASSWORD', roles: [{role: 'readWrite', db: 'your-application-db'}]}). (3) Enable authentication in mongod.conf: add the security section: security: authorization: enabled. (4) Restart MongoDB: systemctl restart mongod (on Linux). (5) Test authentication: mongo -u adminuser -p --authenticationDatabase admin. (6) Update all application connection strings to include credentials. Confirm the application connects successfully before considering the remediation complete.
How do I secure an exposed Redis instance?
Redis security hardening after exposure: (1) Bind Redis to localhost or a private IP only: in redis.conf, change bind 0.0.0.0 to bind 127.0.0.1 (for local-only access) or bind 10.0.1.5 (your private IP). Restart Redis. (2) Enable Redis AUTH password: in redis.conf, add requirepass YOUR-STRONG-PASSWORD. In redis.conf, also set aclfile to a separate ACL file for user-level access control if using Redis 6.0+. Restart Redis. (3) Rename dangerous commands: in redis.conf, rename-command CONFIG '' (empty string disables the command), rename-command FLUSHALL '', rename-command FLUSHDB '', rename-command DEBUG ''. This prevents attackers who do gain access from using configuration-change commands. (4) Disable protected-mode only if you have network controls in place: protected-mode yes causes Redis to refuse connections from non-localhost IPs unless a password is set — keep this enabled. (5) For Redis 6.0+: use ACL LIST to create users with specific permissions rather than a single global password.
How do I secure an exposed Elasticsearch cluster?
Elasticsearch security hardening: (1) For Elasticsearch 8.x: security is enabled by default — if running 8.x without security enabled, you have explicitly disabled it. In elasticsearch.yml, ensure xpack.security.enabled: true. Generate built-in user passwords: bin/elasticsearch-setup-passwords interactive. (2) For Elasticsearch 7.x: enable security in elasticsearch.yml: xpack.security.enabled: true. Also set xpack.security.transport.ssl.enabled: true with appropriate certificate configuration. Run bin/elasticsearch-setup-passwords to set passwords for built-in users (elastic, kibana_system, logstash_system, etc.). (3) For Elasticsearch 6.x: basic security (authentication) requires an X-Pack license — without a license, add a reverse proxy (nginx with basic auth) in front of the Elasticsearch port as an immediate measure. (4) Network binding: in elasticsearch.yml, set network.host: _local_ to bind to localhost only, or specify your private IP. Never use network.host: 0.0.0.0 unless you have verified authentication is enabled and a firewall is in place.
How do I determine what data was accessed during the database exposure window?
Exposure window assessment: (1) Determine the start of exposure: check cloud provider network flow logs (AWS VPC Flow Logs, GCP VPC Flow Logs, Azure NSG Flow Logs) for when traffic to the database port from external IPs began. Check the database's configuration history and deployment logs to identify when the public IP was assigned or the security group rule was changed. (2) Review database access logs during the exposure window: MongoDB audit log (if enabled): db.adminCommand({getLog: 'global'}) for recent events. For databases without built-in audit logging: the absence of logs makes the assessment harder — escalate to assume full data access if logs are unavailable. (3) Check Shodan historical data: Shodan maintains historical records of when a host was first indexed at a given port — shodan host YOUR-IP shows the first_seen timestamp for each service, indicating when Shodan bots first detected the exposure. (4) Look for indicators of ransom-deletion: in MongoDB, check if collections were replaced with ransom note collections (common pattern: a collection named PLEASE_READ or README with a bitcoin payment address). In Elasticsearch, check for deleted indices and a ransom note index.
Do I need to notify affected users or regulators after a database exposure?
Breach notification is required under GDPR Article 33 (notify supervisory authority within 72 hours if there is a risk to individuals' rights), HIPAA Breach Notification Rule (notify individuals within 60 days, HHS within 60 days), CCPA (notify affected California residents in the most expedient time possible), and various state breach notification laws. The key question: was personal data (PII, PHI, financial data) stored in the exposed database? If yes: engage legal counsel immediately. Under GDPR, the default position for an unprotected database that was indexed by Shodan is that a breach occurred, because demonstrating that no unauthorized access took place is effectively impossible. Your legal team should assess the specific data types, the jurisdiction of the affected individuals, and the applicable notification timelines. If the database contained only non-personal operational data: notification may not be required, but document the assessment and decision for your incident record.
How do I prevent database exposure from happening again?
Systemic prevention controls: (1) Network architecture: deploy all databases in private subnets with no internet routing — in AWS: use a VPC with private subnets, route tables with no Internet Gateway route, and Security Groups that only allow inbound connections from application server Security Groups, not from 0.0.0.0/0. (2) Infrastructure-as-code review: require security group and firewall rule changes to go through peer review in pull requests — a database security group that allows 0.0.0.0/0 should fail automated Terraform plan analysis (checkov, tfsec). (3) Cloud security posture management (CSPM): AWS Security Hub, Microsoft Defender for Cloud, or Google Security Command Center automatically flag publicly accessible databases as findings — enable these and review findings weekly. (4) Regular Shodan/Censys monitoring: periodically search Shodan for your organization's IP ranges to identify any unintentionally exposed services. (5) Enforce authentication as code: use Terraform or Ansible to configure database authentication as part of the provisioning process — authentication that requires a manual post-deploy step gets skipped during incidents and rapid deployments.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.