Topic: Eine Idee, die es wert wäre zu realisieren. - page 2. (Read 3340 times)

Die Frage ist nicht ob man was von der Stange nehmen kann, sondern sollte.
Desweiteren habe ich ursprünglich die Nutzung von Interpreter in Frage gestellt
und alle von dir aufgezeigten *Härtungsversuche* sind sowieso selbstverständlich.

Zu deiner Frage:
Ein Service, der u.U Werte in Mio. Höhe vorhält, sollte so konstruiert sein, daß
selbst ein unauthorisierter Shell Zugriff keinerlei Coin-Entwendung ermöglicht
sondern maximal eine Störung verursachen kann.
Interpreter können das Aufgrund des direkt sichbaren Scriptquellen nicht leisten.

Simples Beispiel (PHP/MySQL):
Sobald Shell Zugang existiert (muss noch nicht mal root sein), reichen ein paar
Greps aus, alle DB Connectoren aus den Confs oder direkt aus den Sourcen auszulesen.
Suchen muss man auch nicht lange, ist ja alles *Standard*, da weiss man was man hat.
Dieses Problem haben grundsätzliche alle Interpreter, sei es PHP/Python/Perl oder
eben auch Node. Gerne wird bei MySQL auch der TCP Stack auf Localhost gebindet um
die Kiste nach aussen Unsichtbar zu machen. Mit einer offenen Shell hat sich das
dann auch noch erledigt, Attacken können von der Shell aus Lokal ausgeführt werden,
wobei wahrscheinlich noch nicht mal nötig, da die Zugänge schon ausgelesen sind.
Zur Not werden die Scripte einfach *um nötige Funktionen erweitert*.
Dazu kommt noch, dass die gesamte Cluster Topologie ebenso per Source-Tracking
zu erfassen ist. Deine Scripte müssen ja mit dem Cluster kommunizieren, demnach
liegen zwangsläufig auch die Cluster-Adressen im Script bzw. in den Conf Files.
Kondensiert heisst das, sobald du Interpreter einsetzt kann ein Angreifer nach
Shell Zugang deine GESAMTE Ablauflogik, Connectoren-Zugänge und Cluster-Adressen
auslesen. Selbst wenn du zusätzliche Layer schaltest, ist deine Schwachstelle
IMMER dein Script, da offen, tracebar und unter Kommunikationszwang zur DB.

Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.
Beispiel (C/NoSQL-Lib oder pure libmysql, falls SQL Syntax sein muss):
Als DB-Backend kommt eine Low-Level NoSQL-Lib in Frage, idealerweise ohne TCP Stack
(Min. Latenz), falls TCP zwingend erforderlich ist kommt eine C-Lib in Frage, die Request
aus den ebenfalls kompilierten CGI's abarbeitet. ALLE Zugangsdaten und Cluster-Adressen
sind in der Lib statisch einkompiliert. DB-Verschlüsselung erfolgt durch die Lib NICHT
File- Bzw. OS Basiert, sondern per DATENSATZ. Passt sehr gut zu dem Dokumentenorientierten
Ansatz der DB. Was findet ein Angreifer mit Shell-Zugriff jetzt vor?
Simpel gesagt 3 Dateien. Eine DAT (DB) eine LIB (DB-Cluster-Connector) und eine EXE (CGI).
Selbst mit den derzeit besten Decompilern ist da wenig - innerhab des Zeitfensters -
zu machen. Der Angreifer kann weder auf die DB Zugreifen bzw. Auslesen, noch brauchbare
Rückschlüsse auf die Ablauflogik oder Cluster-Topologie ableiten um weitere Schwachstellen
oder gar das Cold-Wallet im Cluster zu Identifizieren.

Die höhere Startup-Latenz der kompilierten CGI's wird durch den direkten DB-Zugang
egalisiert. Der dabei eingekaufte Sicherheitsvorteil erhöht den Aufwand das System
zu Hacken enorm. Natürlich kann ein Angreifer gefrustet z.B. die DB Löschen aber
der Backup/Reinkarnationserver ersetzt die aus dem Sharding Umgehend (s. Minix/Microkernel)
Diesen Aufwand würde ich mir nicht für einen PopelShop machen aber für Finanzorientierte
Server bei denen es evtl. um Millionen geht mit Sicherheit und das mindestens.

Was ist denn daran sicher, wenn der, bei dem der Server steht zu jeder Zeit dran kann und aus praktischen Gründen wohl auch das Root-Passwort kennt. Selbst ohne das Passwort zu kennen könnte er darauf zugreifen.

Man sollte aber auch Einzahlungen ermöglichen

Ich würde sogar behaupten, dass man für Auszahlungen usw. nicht mal eine Standleitung braucht, sondern auch 32 MBit/s down bzw. ein paar Mbit up genügen würden. Dann dauern Auszahlungsphasen eben ein wenig länger. Das wäre aber nicht so dass man wie beim Webserver viele User zur gleichen Zeit bedienen können müsste.

Ansonsten aber denke ich spricht gar nichts dagegen dass man einen Transaktionsserver online hat. Vielleicht bei nem anderen Provider als der eigentliche Service. Wer mit Zugang zum Server sollte denn wissen, dass es sich um einen Bitcoins-Transaktionsserver für Dienst X handelt, usw!? Hier sehe ich bei "Server im Wohnzimmer" doch ein höheres Sicherheitsrisiko.

Ein Server im Wohnzimmer? Sicher? Sogar sehr! Ausfallsicher/hochverfügbar? Das wohl schon weit weniger...

Es reicht ja schon ein RaspberryPi um Auszahlungen (das ist das einzige, das wirklich ein Hotwallet und damit private keys braucht) zu ermöglichen.

Ähm.. und wo sollte dieser Transaktionsserver dann stehen? Bei mir? Und dann noch Kühlung und Belüftung bzw. insgesamt klimatisiert und Stromausfallsicherheit, etc. - klingt nicht besonders praktikabel.
Wenn der Transaktionsserver bei irgendwem - also z.b. bei mir - zuhause steht, ist das noch unsicherer als in einem RZ.

dann ist noch die Frage, ob das Projekt genug Geld einbringt um eine (mehrere? Verfügbarkeitsanforderungen?) Standleitung zu finanzieren. Dann wäre es eine Option, den Transaktionsserver lokal zu halten. Damit wäre der einzige Zugang ins Netz die Transaktionsschnittstelle zu dem(den) dedizierten Prozessserver(n). Damit lässt sich eine sehr gute Absicherung realisieren. Da das Protokoll sehr effizient gehalten werden kann, hält sich die benötigte Übertragungsleistung abhängig von der Anzahl der Transaktionen/s in Grenzen. Je nach Verfügbarkeit müsste man sich allerdings über Redundanz Gedanken machen. Das hängt aber alles stark vom Projekt selber ab - hier gibt es keine allgemeingültige Architektur für das System mehr.

@TheOtherOne: Mich interessiert immer noch, warum man keine DB von der Stange und keine Standardbibliotheken im Backend nehmen kann und warum ganz allgemeingültig (lokaler?) root Zugriff das ganze Konzept vaporisieren soll.

Ja, das hätte ich auch so gemacht, bin allerdings kein Experte auf diesem Gebiet.

Bei Auslieferung nicht. Ein paar Minuten später schon. Allen anderen gehört der Server sofort wieder abgenommen - das hat die erste Aktion bei einem neuen Dedicated Server zu sein. Und gleich dazu gehören alle Services bis auf den Zugang erst mal dicht bis sie korrekt konfiguriert sind.

Darüber braucht man aber nicht mehr diskutieren das ist die Basiskonfiguration eine dedizierten Webserver. Wenn wir über Finaztransaktionsserver reden dann setze ich die grundlegenden Sache einfach als selbstverständlich voraus.

OTP klingt sehr gut. Scheint wie eine TAN-Liste zu funktionieren.


Ja wir reden aber schon von Root-Server(n) und da ist das nicht per Default so, ist ja schließlich ein Root-Server.
Nur mit einem Webserver kommt man bei diesem Projekt nicht so weit.

Dann kann man den Port auch gleich offen lassen. Allerdings sollte Public Key Auth oder OTP ausreichend sein.


Das ist selbstverständlich. root hat bei einem Standardserver nie Remote Zugang und der Benutzer ist bei Remote Zugang in der Password DB gesperrt. Darüber braucht man nicht mal bei einem stinknormalen Webserver reden.

Nein, ich rede nicht von einem versteckten Port. Der SSH-Port würde nur für Einspielungen von Änderungen (scp) und Adminstrationsaufgaben geöffnet werden und wäre ansonsten geschlossen, d.h. überhaupt nicht erreichbar.



TheOtherOne sprach aber davon, dass sich jemand SSH root-Zugang verschaffen könnte und damit sämtliche Sicherheitsvorrichtungen kompromittieren würde. Doch hier muss ich noch anfügen, dass es unabhängig vom Port sinnvoll wäre, den user root für ssh-login grundsätzlich zu sperren und vielleicht mit sudo arbeiten.

Sich auf darauf verlassen, dass niemand den Port findet ist Scheinsicherheit. Ich habe ehrlich gesagt lieber einen SSH am Port, als einen Webserver. Kennst Du einen Fall bei dem ein Server mit SSH Zugang, Public Key Auth und ordentlich generiertem Key gehackt worden ist? Dann gibt es natürlich noch ein paar Möglichkeiten vor und nach dem Login. Mit einem Transaktionsserver vor Ort braucht man sich darüber gar keine Gedanken machen - dann gibt es erst gar keinen Remote Zugang.

Trotzdem muss der Rechner natürlich administrierbar sein hat also zumindest lokale root Rechte für den Admin (natürlich nicht für den Service). Ich Frage mich also immer noch, was TheOtherOne damit sagen wollte. Vor allem laufen Transaktionsserver mit entsprechender Absicherung und die hängen am Internet ohne dass sie gehackt werden. Bei ein paar Diensten wäre ein Einbruch tatsächlich fatal. Entsprechend gut sind sie gesichert.

Man könnte darüber nachdenken den SSH-Port grundsätzlich per Firewall dicht zu machen wenn man kein SSH braucht. Das müsste über ein geeignetes Webinterface passieren, dessen URL absolut niemand kennen oder erraten kann außer ich bzw. der Betreiber, sonst würde dies ja wieder ein höheres Risiko bedeuten.

Das würde verhindern, dass irgendwer im Normalbetrieb auf die Shell kommt bzw. dies überhaupt versuchen kann.

LOL. Thx. Ich habe aber Zweifel, dass ich im Brigitteforum Leute gefunden hätte die a) derartige skills haben und b) was von Bitcoins wissen/verstehen

Sie hacken auf mir herum weil ich halt nicht genannt habe was die Idee ist. Das ist schon irgendwie blöd. Ist ähnlich wie wenn man Wochen vorher weiß dass man was supertolles zu Weihnachten geschenkt bekommt aber man weiß nicht was es ist. Unerträglich


Deswegen: wo kann man denn eine closed group erstellen zu der man Leute einladen kann? Von Facebook habe ich mich gerade "gelöscht", nachdem man mich mundtot gemacht hat wie einen unmündigen Bürger. Ich durfte nichts mehr posten! Unverschämt. Gut, dass ich wieder aus dem Mainstream heraus bin.

Vielleicht gibt es solche closed groups in Diaspora? Ka.. melde mich gerade an..

Das musst Du mir jetzt erklären.

Ich schrieb, dass Sicherheitsexperten benötigt werden bzw. zu begrüßen wären.
Deswegen ist eine Technologie-Diskussion durchaus angebracht. Wenn sich was eigenes realisieren und absichern lässt, wieso denn nicht?
Andererseits stecken in den vorhandenen Lösungen halt schon unzählige Stunden an Manpower und die haben sich zu Sicherheit auch viele Gedanken gemacht..

Weil sich das ganze Gebilde in einer Nanosekunde Vaporisiert
sobald Root Zugriff existiert.

Warum ist die Sicherheit einer DB, welche vordefinierte Anfragen bearbeitet ausschlaggebend für die Sicherheit des Gesammtsystem?

Warum sollte Obfuscation für serverseitigen Code der den Server nicht verlässt wichtig sein?

Wir reden hier über ein abgestuftes Sicherheitskonzept. Da hängt weder die DB am Netz, noch der JS Code. Wenn es um das Transaktionssystem geht, hängt noch nicht mal ein Standarddienst am Netz.

Ich verstehe das aber genau das ist das Problem.
Also ich würde Never-Ever einen Wallet/Transaktionsbasierten Dienst so hinstellen.

Edit: Aber ich will hier keinen Techno-Thread lostreten. Nur zu...

Unsinn, Standardkomponenten widerspricht in sich schon Sicherheit
und Interpreter-Code lässt sich grundsätzlich nicht wirkungsvoll
*Obfuscaten*, keine Chance.

Ja, wirklich. Wenn man das alles selbst programmieren will wird man ja nie fertig.

Es muss nicht ausgerechnet MySQL sein..