Verstehe die Admins der Installationen nicht

[Gunah]

Warum macht man nicht alles dicht und dann nur das in INPUT wieder auf (via iptables), was wirklich nach außen lauschen soll.
Ist für mich der selber "Fehler" wie bei MongoDB.

klar besser wäre in der Default Installation, dass nur auf 127.0.0.1 gelauscht wird.

*kopf schüttel*, an solche Admins :D

[3dgamer]

So ist es halt....bei 1000 Mitarbeitern eine IT Abteilung aus 4 Leuten? Läuft.
Selbst schon erlebt, im Bewerbungsgespräch nachgefragt. Gelacht & gegangen...

Aber schon richtig, DB ist von außen zugänglich -> alles dichtmachen.

[Snooozel]

Weil es sehr oft sicherlich keine Admins waren sondern Webdesigner oder Hobbybastler die irgendeinem HowTo gefolgt sind.

[Anonymer Nutzer]

weil's egal ist... is ja nix passiert.

[kelox]

Ich bezweifle, dass Admins diese Installationen gemacht haben. Das werden einfach irgendwelche Entwickler sein, die in AWS/Azure etc. sich irgendein Docker Image hergenohmen haben und das hoch gezogen haben. Weil es ja so schön einfach und schnell geht. Die meisten denken doch gar nicht mehr nach was sie machen. Die kopieren nur von Stackoverflow/Medium etc. Und MongoDB ist doch hipp...die ganzen jungen Entwickler rennen solchen Hypes doch hinterher, egal ob es Sinn macht oder nicht MongoDB in einem Projekt zuverwenden.

[Cok3.Zer0]

Gunah schrieb:
--------------------------------------------------------------------------------
> klar besser wäre in der Default Installation, dass nur auf 127.0.0.1
> gelauscht wird.

Ja, wirklich besser, aber nicht gut ;)

[mxrd]

Cok3.Zer0 schrieb:
--------------------------------------------------------------------------------
> Gunah schrieb:
> ---------------------------------------------------------------------------
> -----
> > klar besser wäre in der Default Installation, dass nur auf 127.0.0.1
> > gelauscht wird.
>
> Ja, wirklich besser, aber nicht gut ;)

Na dafür das du hier mit wissen prahlst, ist dieser Kommentar ganz schön unqualifiziert. Ein bind auf localhost ist immer besser als eine iptables konfiguration - das schütze sogar noch, wenn jemand die iptables ausversehen flushed / whatsoever. Ist also offensichtlich gut.

Das man so oder so alles dichtmacht, egal ob alles auf localhost lauscht, ist eh klar.

Aber ich glaube, ihr ergötzt euch hier an Fehlern andere, ohne einen Einblick zu haben, was es so alles gibt. Zum Beispiel ist eine RancherOS-Installation ohne iptables, da es so nicht notwendig ist und auch mit der guest-console in docker nicht einfach möglich. Normaler weise auch mein Problem wenn niemand auf die Idee kommt, seine Development docker-compose.yml mit dem port expose von 9200 auch noch auf dem Production server zu nutzen und so host-ports zu exposen.

Ganz ehrlich, das ganze ist nicht ganz so simple und es werden gerade bei Docker mit den Inter-Microservice-Communication Setups enorm viele Fehler gemacht, unter anderem, weil nicht klar ist, das man dafür nichts exposen muss usw ( internes Netzwerk usw ).

Dennoch pauschal über die Kompetenz andere zu urteilen ist meistens eher ein Indiz für die eigene Inkompetenz.

[Trockenobst]

kelox schrieb:
--------------------------------------------------------------------------------
> Die meisten denken doch gar nicht mehr nach was sie machen

Oder sie werden nicht dafür bezahlt. Ganz ehrlich: was ich da schon an Stundensätzen gesehen habe, macht man im mittelpreisigen Lokal als Getränkeheini mehr Geld.

Ich habe mit großen Installationen zu tun, da wird auch gerne mal das Standardpasswort in der ganzen Firma verteilt, weil der Admin keine Zeit/Lust/Systeme hat das vernünftig zu verwalten.

Wenn dann der gefeuerte Hivi von Remote die DB löscht, ist das Geschrei groß, aber letztendlich beuten sich dann zu viele selbst aus und fixen dass in der Nacht schnell nach.

[Mithrandir]

kelox schrieb:
--------------------------------------------------------------------------------
> Ich bezweifle, dass Admins diese Installationen gemacht haben. Das werden
> einfach irgendwelche Entwickler sein, die in AWS/Azure etc. sich irgendein
> Docker Image hergenohmen haben und das hoch gezogen haben. Weil es ja so
> schön einfach und schnell geht. Die meisten denken doch gar nicht mehr nach
> was sie machen. Die kopieren nur von Stackoverflow/Medium etc. Und MongoDB
> ist doch hipp...die ganzen jungen Entwickler rennen solchen Hypes doch
> hinterher, egal ob es Sinn macht oder nicht MongoDB in einem Projekt
> zuverwenden.

Hast du für deine Behauptungen auch Belege?

Oder bist du einfach nur frustriert, weil du die neuen Technologien nicht mehr verstehst?

[Slurpee]

Mithrandir schrieb:
--------------------------------------------------------------------------------
> Hast du für deine Behauptungen auch Belege?
>
> Oder bist du einfach nur frustriert, weil du die neuen Technologien nicht
> mehr verstehst?

Er hat doch Recht! Ich als junger Entwickler stelle mir am Anfang jedes Projekts erst mal die Frage, wie hipp eine Technologie ist. Wenn es nicht mindestens eine 8 auf der hippskala hat, rühr ich das nicht an, vollkommen egal, ob es den Anforderungen entspricht.

Und das die godlike Systemintegratoren bessere Admins UND bessere Entwickler sind, weiß doch auch jeder!

[tingelchen]

Nun ja. Ein Port Scan auf seinen eigenen Server zu machen, um zu sehen was offen ist, sollte jetzt kein Hindernis sein. Das man diese mittels einer Firewall eben schnell schließen kann, ist jetzt auch kein Hexenwerk, sondern ist Teil des täglichen Handwerkszeugs. Wie etwa ein Hammer für einen Schreiner.

Da von offenen Installationen die rede ist, hat man aber selbst dieses sehr einfache Mittel einfach nicht genutzt. Das sollten sogar Menschen schaffen deren Beruf nicht IT Administration ist ;)

[Cok3.Zer0]

Also, soweit ich das verstanden habe, schützt ein Bind auf localhost nicht vor Zugriff von außerhalb auf REST-Anwendungen!
Man kann einfach, falls auch ein Webserver läuft, bei einem POST-Request reinschreiben, dass der Zugriff auf localhost erfolgen soll. Durch speziell präparierte Seiten mit kurzlebigen DNS-Daten kann sogar eine Ausleitung der Datenbank-Inhalte erfolgen.

Das gab hier mal einen Artikel, aber ich finde ihn momentan nicht.
Und ich bin keineswegs ein Experte, ist auch nicht mein Gebiet. Das sollte m.E. aber ein echter Admin wissen!



1 mal bearbeitet, zuletzt am 17.01.17 18:05 durch Cok3.Zer0.

[mhstar]

> Hast du für deine Behauptungen auch Belege?
>
> Oder bist du einfach nur frustriert, weil du die neuen Technologien nicht
> mehr verstehst?


Nicht alles was "alt" ist muss schlecht sein, auch wenn man es als junger Entwickler mit wenig Erfahrung (=wenig Wissen, was es sonst für Tools gibt) so denkt.

Das Lustigste sind immer die node.js Server. Schlechte Abwärtskompatibilität (ist ja out!), Exceptions bis ganz oben zum Ende des Prozesses, npm und ein gelöschtes Paket das die halben Tools mitreißt (und das hastig wieder hergestellt wird, denn in der schönen Neuen Welt heißt "wirklich löschen?" nur ein Flag setzen, und erst recht nicht löschen - denn man könnte es nochmals brauchen) - einfach w-u-n-d-e-r-s-c-h-ö-n.


> hen NPM took Kik away from the developer, he was furious and unpublished all of his NPM-managed modules.
> To fix the internet, Laurie Voss, CTO and cofounder of NPM, took the "unprecedented" step of restoring the unpublished left-pad 0.0.3 that apps required. Normally, when a particular version is unpublished, it's gone and cannot be restored.
> "Un-un-publishing is an unprecedented action that we're taking given the severity and widespread nature of breakage"
> And that's how JavaScript app development works in 2016. ®

http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

"Schöne Neue Welt"



2 mal bearbeitet, zuletzt am 17.01.17 18:43 durch mhstar.

[mhstar]

> Na dafür das du hier mit wissen prahlst, ist dieser Kommentar ganz schön
> unqualifiziert. Ein bind auf localhost ist immer besser als eine iptables
> konfiguration - das schütze sogar noch, wenn jemand die iptables
> ausversehen flushed / whatsoever.
>
> Dennoch pauschal über die Kompetenz andere zu urteilen ist meistens eher
> ein Indiz für die eigene Inkompetenz.

Was soll denn diese scharfe Anrede. Hat der da einen wunden Punkt getroffen oder was.
Bei einem iptables mit Default "DROP" steht schwarz auf weiß was durchgeht, und alles andere nicht, da brauche ich mich nicht darauf verlassen auf welches Interface sich der Prozess bindet usw.

Ein "iptables ausversehen (sic!) flushed" passiert genau so wenig oft wie "mein root Passwort ausversehen auf abc setzen" oder "einem Prozess ausversehen ein set-uid bit zu vergeben".

Wer außerhalb seines Home-Test-Labs seine iptables "ausversehen" herum"flushed" dem gehört der Server abgedreht.

Wenn ich das mal so "exposen" kann.
Schönes Deutsch übrigens.

[tingelchen]

Man kann einen Service, egal welchen, nicht von *außen* angreifen, wenn dieser nur auf localhost gebunden ist. Das geht Netzwerktechnisch einfach nicht. In deinem Fall wird jedoch nicht der Service selbst angegriffen, sondern ein davor liegender.

Konkret wird die Web API angegriffen, welche einen dann Zugriff auf die dahinter liegende Datenbank erlaubt. Hier hat eben nicht die Datenbank selbst das Problem, sondern der davor liegende Web Service.

Laut Artikel sind aber einige Datenbanken direkt über das Internet zu erreichen. Gerade bei ElasticSearch, welches von Haus aus kein Account Management mit bringt, erlaubt es den Vollzugriff auf alle Daten. Wer das so online bringt, ist halt selbst schuld.