DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Understanding Data Compaction in 3 Minutes
  • How To Use Git Cherry-Pick to Apply Selected Commits
  • Deploying Smart Contract on Ethereum Blockchain
  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication

Trending

  • Understanding Data Compaction in 3 Minutes
  • How To Use Git Cherry-Pick to Apply Selected Commits
  • Deploying Smart Contract on Ethereum Blockchain
  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication
  1. DZone
  2. Data Engineering
  3. Databases
  4. How to Avoid a Malicious Attack That Ransoms Your Data

How to Avoid a Malicious Attack That Ransoms Your Data

With the spate of ransomware attacks affecting MongoDB instances, the company has come out with tips to prevent your data from falling prey to attackers.

Andreas Nilsson user avatar by
Andreas Nilsson
·
Jan. 13, 17 · News
Like (0)
Save
Tweet
Share
3.41K Views

Join the DZone community and get the full member experience.

Join For Free

Recently, there have been reports of malicious attacks on unsecured instances of MongoDB running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

If you believe your database was attacked, see these suggested steps.

These attacks are preventable with the extensive security protections built into MongoDB. You need to use these features correctly, and our security documentation will help you do so. Here are pointers to the relevant documentation and other useful resources:

  • Security is addressed in detail in our Security Manual. We also recently expanded our online training on security as part of the MongoDB University curriculum.
  • Follow the steps in our Security Checklist. It discusses enforcing authentication, enabling access control, limiting network exposure, and other important best practices.
  • The most popular installer for MongoDB (RPM) limits network access to localhost by default. Use this configuration too if you’re installing via another means.
  • MongoDB Cloud Manager and MongoDB Ops Manager provide continuous backup with point-in-time recovery, and users can enable alerts to detect if their deployment is internet exposed (see Figure 1 below).

Figure 1: Create a new alert to notify you if a host is exposed to the public Internet.

  • The latest MongoDB 3.4 release enables you to configure authentication to an unprotected system without incurring downtime.
  • The MongoDB Atlas hosted database service provides multiple levels of security for your database out of the box. These include robust access control, network isolation using Amazon VPCs and VPC Peering, IP whitelists, encryption of data in-flight using TLS/SSL, and optional encryption of the underlying filesystem at-rest.
  • We encourage users who have experienced a security incident with MongoDB to create a vulnerability report. Instructions on how to do this, or to contact us, are provided here.
  • If you are interested in learning more about security best practices, please read our Security Architecture White Paper.

Suggested Steps To Diagnose and Respond to an Attack

How can you tell if an attacker has compromised your data?

  • If access control is configured correctly for the database, attackers should not have been able to gain access to your data. Review our Security Checklist to help catch potential weaknesses.
  • Verify your databases and collections. In the recent cases we’ve seen, the attacker has dropped databases and/or collections and replaced them with a new one with a ransom demand.
  • If access control is enabled, audit the system logs for unauthorized access attempts or suspicious activity.

If you were running an unsecured instance of MongoDB that has been compromised:

  • If you are a commercial support customer, file a P1 ticket ASAP and our Technical Services Engineers can guide you through the process below.
  • Your first priority should be securing your cluster(s) to prevent further unauthorized access. Follow the steps in our Security Checklist.
  • If you had pre-existing users on the system, verify that no users have been added, removed, or modified by running the usersInfo command.
  • Examine logs to find the time of the attack. Look for commands that dropped your data, modified users, or created the ransom demand record.
  • If you take regular backups of the compromised database, you can restore the most recent backup; you will have to evaluate what data may have changed between the most recent backup and the time of the attack. If you use Ops Manager or Cloud Manager for backup, you may be able to perform a point-in-time restore to immediately before the attack. Check whether you are still within the time window for point-in-time restore (the last 24 hours, unless you have configured it otherwise). If so, ensure you perform the restore before the PIT window elapses. If you are past the PIT window, you will still be able to restore a recent backup.
  • If you don’t have a backup or are otherwise unable to restore the data, unfortunately, your data may be permanently lost.
  • You should assume that the attacker has a copy of all data from the affected database(s). Follow your internal security procedures for a data breach.
  • Finally, refer to our security best practices and resources to protect your data in the future.
Data (computing) Database security MongoDB

Published at DZone with permission of Andreas Nilsson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Understanding Data Compaction in 3 Minutes
  • How To Use Git Cherry-Pick to Apply Selected Commits
  • Deploying Smart Contract on Ethereum Blockchain
  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: