Login
Newsletter
Werbung

Thema: Der MongoDB-Erpressungstrojaner und die Bedeutung von sicheren Standardeinstellungen

10 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
3
Von blablabla233 am Sa, 14. Januar 2017 um 11:33 #

Wer seine DB unabsichtlich von aussen sichtbar macht ist schlichtweg unfähig, ganz zu schweigen von einer Firewall. Dass ist genau der Grund weshalb unfähige keine Systeme bauen sollten! Da sind sichere Grundeinstellungen nur soviel wert wie der Admin der sich darum kümmert.

[
| Versenden | Drucken ]
  • 1
    Von der-don am Sa, 14. Januar 2017 um 14:24 #

    Ich verstehe das auch nicht ... Jeder Server hängt in einer vernünftig geplanten Umgebung hinter einer Firewall, Datenbank- und Applikationsserver bei einfachen Konfigurationen dann im gleichen VLAN - ansonsten sind auch die nochmal durch eine Firewall getrennt. Die Applikation wird dann über eine WAF bzw. grundsätzlich einen Reverse-Proxy bereitgestellt (Falls HTTP), andere Dienste per gesicherten Tunnel.

    Ist das so schwer zu begreifen?

    [
    | Versenden | Drucken ]
    • 0
      Von der-don am Sa, 14. Januar 2017 um 14:26 #

      Ich überlege gerade ... Selbst wenn ich wollte - und kein Passwort für den Root-Benutzer der DB vergeben würde (Wir verwenden überwiegend MariaDB / MySQL, aber das spielt keine Rolle) würde niemand Zugang zu der Datenbank bekommen. Wie kann man so viel falsch machen eh?

      [
      | Versenden | Drucken ]
      • 0
        Von blablabla233 am Sa, 14. Januar 2017 um 15:40 #

        Es zeugt von grunsaetzliche Unfaehigkeit. Zumal Amazon ja noch gratis eine simple Firewall bereitstelt (Security-groups) solchen Firmen sollte Verboten werden mit Daten von Kunden umzugehen (ausser sie lassen 1mal pro Monat eine Sec-Firma alles durch checken). Das ist fahrlaessig!

        [
        | Versenden | Drucken ]
1
Von Mango am So, 15. Januar 2017 um 00:40 #

Das Problem bei MongoDB war, dass lange Zeit keine echte Authentifizierung implementiert war, obwohl MongoDB vor allem für die partitionierte und redundante Datenspeicherung genutzt wird, und dafür der Datenbankzugriff per Netzwerk natürlich erlaubt werden muss.

Bei der "Cluster"-Variante von MySQL ist das übrigens immer noch so - für die MySQL-Cluster-NDB-Datenbanken gibt es keinerlei Verbindungs-Authentifizierung.

In beiden Fällen hätte man händisch eine (unvollständige) Absicherung per "iptables" anhand der Client-IP-Adressen vornehmen können - vorausgesetzt, dass die Clients statische IP-Adressen haben. Bei dynamischen Client-IP-Adressen (z.B. wenn der DB-Server remote in der "Cloud" läuft, der Entwicklungsserver aber im LAN) hätte man zusätzlich einen Tunnel mit IPsec, OpenVPN o.ä. einrichten müssen. Eine angepasste und sichere "iptables"- und/oder VPN-Tunnel-Einrichtung ist aber auch für langjährige Linux-Administratoren eine echte Herausforderung, und nicht mal so eben gemacht.

Meiner Meinung nach liegt die "Schuld" in diese Fällen maßgeblich bei den Anwendern, die entweder die Dokumentation nicht richtig gelesen haben (denn die fehlende Authentifizierung war bei MongoDB gut dokumentiert), oder die Systeme trotzdem, ohne die notwendige Absicherung, auf öffentlich erreichbaren Servern eingesetzt haben.

Dass die Authentifizierung erst so spät implementiert wurde, ist natürlich auch kein Ruhmesblatt für den Hersteller - aber wenn man eine so tolle verteilte Datenbank, deren Implementierung vermutlich einen Riesenbatzen "Startup-Kapital" verbrannt hat, als Open-Source praktisch "geschenkt" bekommt, liegt die "Bringschuld" nicht nur beim Hersteller, sondern (auch) beim Anwender.

Ich selbst hatte mir MongoDB vor längerer Zeit mal für ein Projekt angeschaut - und die Nutzung dann u.a. wegen der fehlenden Authentifizierung wieder verworfen. (Der andere Grund war, dass die Behebung von Cluster-Problemen manuelle Eingriffe erforderte, die sehr fehlerträchtig waren. Da man so etwas zwar nur selten, dann aber oft unter starkem Zeitdruck machen muss, war mir der Einsatz von MongoDB damals zu riskant.) Insofern freut es mich natürlich, dass MongoDB offenbar inzwischen eine Verbindungs-Authentifizierung ermöglicht, und ich werde mir den aktuellen Stand des Projekts in Kürze noch einmal ansehen. Die Features von MongoDB waren immer schon beeindruckend (im Open-Source-Bereich sonst nur vergleichbar mit "CouchDB"), und die Implementierung ist ein Genuss für jeden, der sich gerne mit trickreich optimierten Algorithmen beschäftigt.

[
| Versenden | Drucken ]
  • 0
    Von blablabla233 am So, 15. Januar 2017 um 00:57 #

    Wieso die Auth nicht über ssh herstellen? Ist ja auch nicht sinnvoll dass jeder seine Auth und verschlüsselung macht obwohl es bestende Lösungen gibt (die sicherheitstechnisch etabliert sind). Die von Mysql ist es nicht, ein bsp:
    https://www.exploit-db.com/exploits/19092/
    gibt noch viele mehr...


    Es gibt viele DB's und Dienste die keine Auth bzw verschlüsselung haben und das ist auch gut so.

    [
    | Versenden | Drucken ]
    0
    Von Verflucht am So, 15. Januar 2017 um 02:26 #

    Wie bitte? Ein sicheres iptables setup ist für langjährige Administratoren eine Herausforderung?

    Was für ein schmarren - Ein iptables.sh dass erstmal alles reinkommende das nicht explizit erreichbar sein soll auf REJECT setzt und für erreichbare Ports wenn public -s nicht setzen und ansonsten sourceip/cidr auf ACCEPT vor angesprocher default rule ist eine Herausforderung?

    Das sind basics die man sich binnen weniger Stunden aneignen kann und wenn man dazu nicht in der Lage ist hat man sich nicht als Administrator zu bezeichnen zumal sowas auf jeden verdammten Rechner gehört egal wieviele Firewalls davor stehen -> layered security

    [
    | Versenden | Drucken ]
    • 0
      Von Mango am So, 15. Januar 2017 um 03:56 #

      Die Herausforderung besteht darin, bei verteilten Datenbanken, die womöglich auch noch auf verschiedenen Cloud-Servern bei unterschiedlichen Hostern laufen, und deren Port-Nutzung nicht immer optimal dokumentiert ist, den Überblick über die diversen Kommunikationswege nicht zu verlieren, und die Aufgaben unter den Beteiligten, auch was die spätere Wartung angeht, klar zu definieren.
      Auch wenn Mitarbeiter wechseln, "mal eben" ein Development-System aufgesetzt werden soll, oder die Programmierer das Ganze selbst installieren (und leider oft die Netzwerksicherheit nicht als ihre Aufgabe ansehen, oder sich eben auf die Defaults des Cloud-Anbieters verlassen).
      Für viele Programmierer, und auch viele Administratoren, sind "iptables"-Regeln auch durchaus eine Herausforderung.
      Letztendlich kann ich mir die hohe Zahl an unsicheren MongoDB-Installationen aber nur mit fehlendem Problembewusstsein erklären - man wächst zwar mit den Jahren in vieles hinein, aber bis dahin wurschtelt man sich eben durch. Je nach Firmenkultur und persönlicher Motivation und Möglichkeit bleibt es dann auch jahrelang beim Durchwurschteln, weil das oft (betriebswirtschaftlich gesehen) "gut genug" ist - bis irgendwann mal eine Datenbank ungeschützt im Internet steht, und von Kriminellen verschlüsselt werden kann.
      Dass das Phänomen universell ist, sieht man daran, dass die Leute, die die Lücke jetzt ausgenutzt haben, offenbar auch nicht in der Lage waren, eine funktionierende Infrastruktur für ihre Erpressungen zu implementieren.
      Offenbar können "Showstopper"-Fehler also jedem passieren - wer die Komplexität und Managementprobleme bei verteilten Systemen nicht sieht, wem also das Problembewusstsein fehlt, der hat schon verloren. (Und damit beziehe ich mich ausdrücklich auf die Kommentare, die meinen, dass ein paar einfache Firewallregeln ausgereicht hätten.) Hier würde ich mich den Leuten anschließen, die eine funktionierende "Firewall" als ein Gesamtkonzept sehen. Wenn man separate VLANs machen will und sollte, aber aus irgendeinem Grunde ein "Cloud"-Hosting erfolgen soll - und um ungeschützte Cloud-Server ging es ja im ursprünglichen Artikel hauptsächlich - dann ist das durchaus eine Herausforderung. Es ist möglich, aber ziemlich umständlich, und, wie gesagt, aktuell (noch) eine ziemliche Herausforderung, eine verteilte Cloud-Infrastruktur gegen unberechtigte Zugriffe abzusichern.

      [
      | Versenden | Drucken ]
      • 0
        Von blablabla233 am So, 15. Januar 2017 um 13:25 #

        Du redest von Herausforderung, ist es nicht, nicht im technischen sinne! Das management ist auch nur eine kleine, deshalb gibt es config-management (bsp ein DB server wird nur mit geoffnetem ssh verteilt dieser wiederum erhaelt sein cert vom management server und verbindet sich mit der "master DB") herumwurschtelnde Admins koennen das gerne zuhause machen aber NICHT bezahlt in einer Firma (stell dir diese qualitaet mal bei Automechaniker vor, huch rad flog weg, naja er wurschtelte halt an den schrauben bisschen rum, 30000 mal).

        PS: Wenn Admins iptables (wir reden von den simplen) als herausforderung sehen sind sie im falschen geaschaeft (das ist grundwissen LPI 101).

        [
        | Versenden | Drucken ]
        0
        Von Verflucht am So, 15. Januar 2017 um 15:08 #

        Es ist eben keine besondere Herausforderung sondern gehört zu den absoluten Basics eine Maschine die man gedenkt aus dem Netzwerk erreichbar zu machen erst einmal abzusichern BEVOR da überhaupt Daten gespeichert werden

        Und es ist scheißegal wieviele potentielle clients aus wievielen Netzen legitim Zugriff darauf brauchen - Entweder die clients haben statische IP Adressen oder kommen per VPN daher womit Ihre source IP plötzlich auch nicht mehr dynamisch ist

        Wenn das für einen Administrator eine Herausforderung ist dann fehlt ihm jegliche Qualifikation für seinen Job

        Ich gehe sogar soweit zu sagen dass jeder der in den letzten zumindest 5 Jahren nicht auf die Idee gekommen ist automatisierte vulnerability scans auf seine Systeme zu implementieren und da nicht selbstverständlich jede neue Instanz aufnimmt entweder niemals qualifiziert war oder seine Qualifikation von vor 15 Jahren heute nicht mehr ausreichend ist

        Das wirkliche Problem sind Schwachköpfe die noch nichtmal netstat -l kennen und auch Datenbanken die nur von localhost angesprochen werden aus dem Netz erreichbar lassen statt sie an das loopback device zu binden

        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung