preface

Recently, a large number of MongoDB instances have been attacked due to a configuration vulnerability that allows hackers to log in to MongoDB instances without authentication, delete large amounts of data, and extort victims to pay a ransom to get their data back. To date, a surprising number of MongoDB instances have been hijacked. More abominable is, after the hacker deletes the business database, left this paragraph of mocking + blackmail article in the database inside. Big U simply translated: “Your database can be accessed via public IP password free, what the hell do you think?” Dau was so scared that it quickly checked its cloud MongoDB product for this vulnerability and confirmed that there was no risk of attack.





Cause analysis of vulnerability

In fact, it is not difficult for those familiar with MongoDB to find that the reason for the bug is very simple and has a long history. Basically, this was a minor oversight in MongoDB’s early design. In order to make it easier for developers to use MongoDB, complicated connection configuration and authentication methods are not required. By default, authentication is not required, that is, you can log in without password. In the same way, other types of databases, such as MySQL, may be attacked as long as they are configured to allow password-free public IP addresses.

Through the investigation, we found that the hacked MongoDB instance should meet the following two conditions:

  • MongoDB instances require password-free login

  • MongoDB instances open public network access

    Through the analysis of the above reasons, it is generally the following two reasons that lead to tragedy:

  • MongoDB users do not have high security awareness (consider data as dispensable, not critical service)

  • MongoDB users, who are weak in operation and maintenance, didn’t expect this





UCloud UDB MongoDB safeguards

In view of the above two trigger conditions, UCloud UDB MongoDB product has been optimized and enforced security measures at the product level at the beginning of design for security consideration, which fundamentally eliminates the possibility of instances being attacked.

For the first condition, MongoDB products require authentication. Customers who have used our UCloud UDB MongoDB products know that customers must enter root password with sufficient password complexity when applying for cloud MongoDB products. In any case, you need to enter the correct password and the database name for authentication when connecting to cloud MongoDB.

For the second condition, the MongoDB product does not provide a public IP address. Therefore, all operations connected to the MongoDB instance must be accessed using the internal IP address of the cloud host UHost product in the same area and account. That is, the MongoDB product fully realizes VPC Intranet isolation. Bind_ip is forcibly set to the internal IP address of the MongoDB instance in the configuration file.

In addition, it is worth mentioning that even if UDB MongoDB encounters other hacker attacks, there is no possibility of data being extorted. UDB MongoDB provides a complete data backup mechanism to ensure data security.





How can I restore the self-built MongoDB service on the UHost

  • We recommend you to use our UDB MongoDB, our cloud MongoDB product documentation link is as follows:


Database_cloud database_mongodb -UCloud Document center

  • To harden the security of the self-built MongoDB of the existing cloud host, perform the following steps:


  1. Enable password authentication to access MongoDB (Keyfile authentication is recommended for replica sets or Mongos clusters, and keyfile is used for UDBs by default).
  2. Do not access MongoDB using a public IP address (that is, set bind_IP to the internal IP address of the cloud host or 127.0.0.1 in the configuration file).
  3. If authentication is used, you are advised to change the password to a password complex enough to prevent brute force cracking





How do I migrate from cloud host to cloud MongoDB

Generally, MongoDB’s cloud migration strategy is realized through the high availability of replica sets, but network connectivity needs to be ensured first (which is responsible for or assisted by general cloud computing vendors). The cloud DB is used as the Secondary node of the self-built DB. When the data on both sides are completely consistent and the data is confirmed to be normal, a high-availability switch is performed manually to switch the service from the self-built DB to the cloud DB. When the switchover is completed, the cloud DB can be successfully elected as a new Primary node. At this time, rs.remove can be used to remove the self-built DB node on the new Primary node, thus realizing the smooth migration of cloud on MongoDB. Take the self-built MongoDB as a replica set of three nodes, and now want to migrate to the cloud. The steps are as follows:


  1. Open up the network between the target and source libraries. This step is not discussed in detail. Simply speaking, if the source library itself is arranged on the cloud host where the cloud service provider is located, then generally speaking, the network has been through for resources under the same account; If from other IDC room to migrate to cloud MongoDB, you can do a proxy to achieve network connectivity.

  2. The replica set of source DB and target DB is established, with the source database as the master node and the target database as the slave node, and the master and slave are established for replication. Note also that the authentication methods of accounts are consistent, that is, whether auth is turned off or on, the name of the replica set is consistent, and the keyfile used by each node is consistent. The three nodes must be consistent; otherwise, they cannot be synchronized. Assume that the source DB is a replica set of three nodes, and now want to migrate to the cloud, the replica assembly diagram needs to be made as follows:

  3. After the synchronization is complete, check checks the node data integrity, adds the IP addresses of the target DB to the connection string URI of the replica set, and restarts the application layer connection client.

  4. A secondary node on the cloud is selected as the primary candidate node, and its election priority is increased to artificially trigger the election process of the replica set (see rs.reconfig() for details). In this way, a Secondary node in the MongoDB cloud database can be promoted to a new Primary node. The structure after the promotion is shown as follows.

  5. After confirming that services are normal and data is normal, delete the IP addresses of these source DB servers from the connection string URI of the replica set and restart the application layer connection client.

  6. Log in to the Primary node of the MongoDB cloud database and delete the self-built DB data nodes one by one, so that only a few nodes of the cloud database are reserved.

  7. Migration completed.


The above process can be smoothly migrated to the cloud database. In fact, there is still room for optimization in Step 3 and Step 5. You can configure urIs in advance, including urIs before change, urIs in intermediate state, and URIs after change. This policy shortens the impact time on services.





summary

In addition, it is worth mentioning that UCloud is the first domestic cloud computing manufacturer to launch cloud MongoDB products and Mongos sharding cluster. Compared with other competing products, UCloud MongoDB also has more abundant MongoDB versions and architectures for customers to choose according to their own business 🙂

—————— whisper to you ——————


Now register to use UCloud, there are five limited-edition gift boxes waiting for you to open, you can enjoy up to 3000 yuan voucher cash back, on the cloud fast one step! Active portal: UCloud! 3000 yuan limited edition gift box waiting for you to open!

In addition, want to experience the best service and the most powerful discount in the field of Cloud computing in China? Please add UCloud operation sister’s personal wechat account: Surdur




— — —

Related reading recommendations:

What you Need to know about Distributed Databases (I)

What you Need to know about Distributed Databases (Middle)

What you Need to know about Distributed Databases

This article is provided by the UCloud Relational Storage Development Team.


Questions & attention are welcome (*////, ////*)

The above.