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.
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).
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
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.
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).
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