-1

To my surprise, my database was empty after not looking at it for a week. There were collections and a few rows of data. It's running on a digital ocean 14.04 Ubuntu droplet. Mongod is running on the default port, no password or bind ip (I have enabled bind ip now though)

Anyways I check the logpath /var/log/mongodb/mongodb.log to see what happened. I see dropDatabase DB_DROPPED starting. and 185.129.62.63:41783 which originates from Paris France. I'm in Hong Kong! So.... the only way I can access my mongo shell is via ssh with my username and pass.

Did someone figure out my ssh username and pass and then go to usr/bin run mongo then db.dropDatabase()? or is there another way to hack my mongo shell?

Just wondering if this will happen again (some dude deleting my data) or maybe I have some automatic db.dropDatabase() setting running (i doubt the latter).

below are the logs.

Tue Apr 18 05:36:39.251 [conn894] end connection 216.218.206.66:30916 (4 connections now open)
Tue Apr 18 05:36:52.241 [initandlisten] connection accepted from 216.218.206.66:35132 #895 (5 $
Tue Apr 18 05:36:52.430 [conn895] end connection 216.218.206.66:35132 (4 connections now open)
Tue Apr 18 16:44:55.121 [initandlisten] connection accepted from 185.129.62.63:41448 #896 (5 c$
Tue Apr 18 16:44:56.052 [initandlisten] connection accepted from 185.129.62.63:41783 #897 (6 c$
Tue Apr 18 16:44:57.426 [conn896] end connection 185.129.62.63:41448 (5 connections now open)
Tue Apr 18 16:44:57.522 [conn897] end connection 185.129.62.63:41783 (4 connections now open)
Tue Apr 18 16:44:59.409 [initandlisten] connection accepted from 185.129.62.63:42904 #898 (5 c$
Tue Apr 18 16:45:00.580 [conn898] dropDatabase DB_DROPPED starting
Tue Apr 18 16:45:00.580 [conn898] removeJournalFiles
Tue Apr 18 16:45:00.585 [conn898] dropDatabase DB_DROPPED finished
Tue Apr 18 16:45:01.208 [conn898] dropDatabase easysmile starting
Tue Apr 18 16:45:01.208 [conn898] removeJournalFiles
Tue Apr 18 16:45:01.211 [conn898] dropDatabase easysmile finished
Tue Apr 18 16:45:01.756 [conn898] dropDatabase admin starting
Tue Apr 18 16:45:01.756 [conn898] removeJournalFiles
Tue Apr 18 16:45:01.758 [conn898] dropDatabase admin finished
Tue Apr 18 16:45:02.361 [conn898] dropDatabase cool_db starting
Tue Apr 18 16:45:02.361 [conn898] removeJournalFiles
Tue Apr 18 16:45:02.362 [conn898] dropDatabase cool_db finished
Tue Apr 18 16:45:03.579 [FileAllocator] allocating new datafile /data/db/DB_DELETED.ns, fillin$
Tue Apr 18 16:45:03.585 [FileAllocator] done allocating datafile /data/db/DB_DELETED.ns, size:$
Tue Apr 18 16:45:03.585 [FileAllocator] allocating new datafile /data/db/DB_DELETED.0, filling$

Tue Apr 18 16:45:03.587 [FileAllocator] done allocating datafile /data/db/DB_DELETED.0, size: $
Tue Apr 18 16:45:03.588 [FileAllocator] allocating new datafile /data/db/DB_DELETED.1, filling$
Tue Apr 18 16:45:03.589 [FileAllocator] done allocating datafile /data/db/DB_DELETED.1, size: $
Tue Apr 18 16:45:03.596 [conn898] build index DB_DELETED.DB_DELETED { _id: 1 }
Tue Apr 18 16:45:03.601 [conn898] build index done.  scanned 0 total records. 0.005 secs
Tue Apr 18 16:45:04.274 [conn898] end connection 185.129.62.63:42904 (4 connections now open)
Wed Apr 19 02:37:33.739 [FileAllocator] allocating new datafile /data/db/easysmile.ns, filling$
Wed Apr 19 02:37:33.746 [FileAllocator] done allocating datafile /data/db/easysmile.ns, size: $
Wed Apr 19 02:37:33.746 [FileAllocator] allocating new datafile /data/db/easysmile.0, filling $
Wed Apr 19 02:37:33.748 [FileAllocator] done allocating datafile /data/db/easysmile.0, size: 6$
Wed Apr 19 02:37:33.752 [FileAllocator] allocating new datafile /data/db/easysmile.1, filling $
Wed Apr 19 02:37:33.754 [FileAllocator] done allocating datafile /data/db/easysmile.1, size: 1$
Wed Apr 19 02:37:33.755 [conn863] build index easysmile._SCHEMA { _id: 1 }
user411247
  • 1
  • 2
  • 2
    Many installation instructions for MongoDB offer notoriously insecure default access controls (i.e. none) and if your firewall allows incoming connections to your MongoDB your deployment may well be one of the [many thousands](https://cispa.saarland/wp-content/uploads/2015/02/MongoDB_documentation.pdf) that is all too easily hacked... BTW 185.129.62.63 is the ip-address for a tor server in Denmark – HBruijn Apr 19 '17 at 07:42

1 Answers1

4

The log is pretty clear - your DB server is open to the internet - not a good idea!

When it says "connection accepted from 185.129.62.63", that means that a client program (perhaps the mongo shell, perhaps a different application) running on 185.129.62.63 (or tunneling through there) made a connection to your DB server, and it was accepted; the further log entries show your intruder deleting your data.

It's unclear whether you have had authentication enabled on your MongoDB server or not; probably not, given what has happened.

In any case, you need to learn your lesson; apply the steps in the MongoDB Security Checklist urgently, then restore your data from your backup (you do have a backup, don't you?), and don't make the same mistakes again.

Vince Bowdren
  • 198
  • 8