Dipl.-Inform. Carsten Eilers

Eigentlich ist "Secure by default" und "Secure by deployment" heutzutage üblich - bei der Installation einer Software werden nur die nötigen Funktionen installiert/aktiviert, und die werden sicher konfiguriert. Jedenfalls sollte das so sein. Dass immer mal wieder gewisse Programme unschönen Zusätze installieren ist ein anderes Problem (und eigentlich ein Grund, diese Programme gar nicht zu verwenden statt nur die unliebsamen Beigaben zu löschen).

Und eigentlich ist es selbstverständlich, dass man von außen zugängliche Dienste mit einer Authentifizierung vor unbefugten Zugriffen schützt. So selbstverständlich, dass das eigentlich die Default-Konfiguration sein sollte (was das Problem auf das Setzen eines sicheren Passworts reduziert, woran aber auch immer wieder Admins scheitern).

... - aber wehe, wenn das nicht stimmt!

Ich weiß nicht, wieso das bei MongoDB nicht der Fall ist. Aber schon die Annahme, dass nur vom localhost aus auf die Datenbank zugegriffen wird, ist nicht zwingend richtig. Eigentlich läuft die Datenbank meist doch schon aus Performancegründen auf einem eigenen Server. Und dann muss natürlich von einem oder mehreren anderen Servern darauf zugegriffen werden. Was eine Zugriffskontrolle zwingend notwendig macht. Also eine sichere Default-Konfiguration sieht in meinen Augen anders aus. Vor allem, weil schon die "Nur localhost darf zugreifen"-Lösung nicht unbedingt sicher ist - was ist, wenn auf dem localhost mehrere Anwendungen laufen, von denen aber nur eine auf die Datenbank zugreifen soll? Und eine der anderen Anwendungen bösartig ist oder kompromittiert wurde? So was soll ja vorkommen.

Im Fall von MongoDB kommen nun drei Faktoren zusammen: Eine nicht unbedingt sichere Default-Konfiguration (um das harte "unsicher" zu vermeiden), eine nicht gerade optimale Dokumentation - und unerfahrene Admins.

MongoDB ist nur teilweise schuldigt!

Ob die daraus entstehende Fehlkonfiguration eine Schwachstelle ist oder nicht, darüber kann man streiten. Aber nicht darüber, wer am Ergebnis Schuld ist. Und das ist nicht MongoDB, auch wenn die viel dazu beigetragen haben.

Schuld an den offenen Datenbanken "in the Wild" haben auf jeden Fall die jeweiligen Admins. Denn man darf sich eben nicht darauf verlassen, dass eine Installation per Default sicher ist. Was dieses Beispiel ja eindrucksvoll gezeigt hat. Für die Absicherung seiner Systeme ist jeder Admin selbst und allein verantwortlich. Und eigentlich sollte jeder Admin wissen, dass man zum Zugriff auf von außen zugängliche Dienste Zugangsdaten oder ähnliches braucht. Jedenfalls solange es nicht um einen öffentlichen Dienst wie den Webserver geht.

Ist das nicht der Fall, muss doch irgend was nicht stimmen. Da müssen doch sämtliche Alarmlampen und -tröten los gehen. Wenn man keine Authentifizierung konfiguriert hat, stimmt in den allermeisten Fällen irgend was nicht.

Ach ja: Wieso ist der MongoDB-Port eigentlich aus dem Internet zugänglich, wenn er doch meist nur lokal genutzt wird? Da scheint es ja auch um die Firewall nicht gerade gut bestellt zu sein. Da sollten doch per Default alle nicht benötigten Ports dicht sein - wieso kommt man dann von außen an die Datenbank? Da liegt also noch mehr im Argen.

Es gibt was zu tun...

Wann haben Sie denn ihre Konfiguration das letzte Mal überprüft? Das wäre doch jetzt eine gute Gelegenheit, da mal einen kritischen Blick drauf zu werfen. Sogar dann, wenn Sie MongoDB nicht nutzen. Vielleicht gibt es ja auch andere per Default unsichere Konfigurationen.

Carsten Eilers