Eine Idee, die es wert wäre zu realisieren.

[amunet]

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

Das musst Du mir jetzt erklären.

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.

Sich auf darauf verlassen, dass niemand den Port findet ist Scheinsicherheit.

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.

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.

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.

[mezzomix]

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.

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

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.

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.

[amunet]

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.

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

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

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.

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.

[mezzomix]

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.

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.

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.

[amunet]

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.

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

[mezzomix]

Wenn wir über Finaztransaktionsserver reden ...

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.

[amunet]

Wenn wir über Finaztransaktionsserver reden ...

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.

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

[Sukrim]

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.

[amunet]

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

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.

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

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.

[TheOtherOne]

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.

[mezzomix]

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

Für einen Transaktionsserver bei dem richtig Geld im Spiel ist, kann ich mich mit dem Wohnzimmer irgendwie nicht so recht anfreunden. Ein überwachtest Rechenzentrum/Bürogebäude wäre da schon schöner - vor allem wenn die Zugangskontrolle mit der Notabschaltung des Systems gekoppelt wird.

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.

Ein unbemerkter root Access ist auch für compilierten Code fatal. Wird das eindringen bemerkt ist sowieso speicherlöschen und Notabschaltung angesagt.

Bevor ich das gesammte System selber codiere und was weiss ich wie viele Fehler einbaue, setze ich hier lieber auf Standardlösungen kombiniert mit angepassten Überwachungs- und Sicherungsmechanismen.

Um das zu verhindern lohnt es sich Old-School Kompilierte CGI's einzusetzen.

CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben. Mit welcher Technik die Schnittstelle betrieben wird (Scriptsprache, kompilierter Code) halte ich nicht für ausschlaggebend.

Ein bischen sorge macht mir bei diesen Systemen das Betriebssystem. Auch hier ist eine eigene Implementierung meistens nicht realistisch. Wenn schon der Layer 2 Treiber Lücken hat, ist die restliche Absicherung auf Sand gebaut. In kritischen Projekten setzen wir dafür externe Überwachung ein. Macht die Sache aber nicht kostengünstiger.

[Zephir]

Möchtest du nicht den Titel deines Threads auf einen seriöser klingenden Titel ändern.
Würde deutlich mehr Aufmerksamkeit darauf ziehen, denn so schreckt es potentielle Mitstreiter ab, bevor sie den Thread öffnen.

zB. "Eine Idee, die es wert wäre zu realisieren." oder "Habe eine Idee mit hohem Potential, suche Mitstreiter." etc.

P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

[mezzomix]

P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Vieleicht "Es"? SCNR 

[Sukrim]

Irgendwer ist immer root, ohne Vertrauen geht gar nichts wenn du nicht Bitcoins verwendest sondern IOUs (also Schuldversprechen). Sobald jemand in deinen Dienst was einzahlt, hat derjenige keine Bitcoins, nur mehr dein Verprechen, dass du sie irgendwann irgendwie zurückzahlst.

Einzahlungen kann man ganz einfach in der Blockchain überprüfen, dazu muss man nur die benutzten Adressen kennen, sonst gar nix.
Auszahlungen brauchen auch quasi keinen Netzwerktraffic (ein paar 100 Bytes für die Transaktion ins Bitcoinnetz) - aber irgendwo muss eine Maschine stehen, die Zugriff auf die Keys zu den Einzahlungsadressen hat. Quasi jeder Hack wurde dadurch ermöglicht, dass jemand Zugriff auf den Server erlangt hatte, der Auszahlungen ermöglicht.

Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

[Zephir]

P.S.: Bist du eine "Sie" "Er" oder "Mehrere" ? Da polarstorm beim skype Gespräch von einem "Er" redet und du von einer "Sie"

Vieleicht "Es"? SCNR 

Geht mir ja gar nicht ums Geschlecht, sondern eher ob "Sie" schon Mehrere sind.

[mezzomix]

Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

Weiss gar nicht ob ich das schon irgendwo geschrieben hatte: Zumindest bei einem neu eingeführten System würde ich mindestens in der Anfangszeit die Auszahlungsfunktion des System mit nachgeschalteter manueller Kontrolle laufen lassen.

Zwischen Transaktionsserver und einem späteren Auszahlungsserver lässt sich dann mit den entsprechenden Erfahrungswerten auch wunderbar ein Test schalten, der typische Auszahlungsmuster überwacht und die Auszahlungsfunktion trennt bzw. nur noch manuelle Prüfung zulässt, sobald eine Abeichung vom bekannten Muster auftritt.

Nebenbei wäre ein Penetration Test auf einem parallel dazu laufenden identichen Dummy System nicht falsch.

[TheOtherOne]

CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben.

Da kommst du nicht drumherum, egal wieviel Layer du dazwischen Schaltest. Letztendlich verarbeitest du Anfragen aus dem Web und
damit hast du eine bestehende Reaction-Chain.

Mit welcher Technik die Schnittstelle betrieben wird (Scriptsprache, kompilierter Code) halte ich nicht für ausschlaggebend.

Falsch, wie oben beschrieben. Genau das macht den Unterschied. Bei Script bist du deine Coins los. Kompiliert nicht.

[TheOtherOne]

Eventuell sollte man sich auch endlich mal von dem Modell "man kann 24/7 Auszahlungen SOFORT vornehmen" verabschieden?

Wird schon gemacht, grössere Auszahlungen, die aus dem Cold-Wallet kommen werden nur in einem zugelassenen, vom CW-Server definierten Zeitfenster
ausgeführt. Anfragen ausserhalb des Zeitfensters werden vom System verworfen bzw. gar nicht erst beantwortet, da der Port
geschlossen bleibt.

[mezzomix]

CGI ist Web. Ich würde eine Teufel tun, einen Webserver als externe Schnittstelle eines hochsicheren Transaktionsserver(!) zu betreiben.

Da kommst du nicht drumherum, egal wieviel Layer du dazwischen Schaltest. Letztendlich verarbeitest du Anfragen aus dem Web und
damit hast du eine bestehende Reaction-Chain.

Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.

[TheOtherOne]

Der Transaktionsserver ist normalerweise ein eigenständiges System. Ob da ein Webserver dranhängt, eine Middleware oder ein Applikation ist nicht relevant. Das System führt Transaktionsaufträge eigenständig aus und überprüft diese auch selbständig. Der Frontendserver hat da nichts zu melden.

Transaktionsserver können ohne Event NIX machen. Der originäre Trigger kommt IMMER aus dem Netz.
Handlungsisolation gibt es nicht. Oder woher hat der TAS die Information und Daten eine Auszahlung zu veranlassen?
Maschinelle Intuition? 

Du kannst es Drehen wie du willst und Layer über Layer einsetzen um die gefühlte Sicherheit
zu verbessern aber sobald die den Trigger auslösende Schnittstelle (hier Das Web) offen ist
(Scripts) hast du mit allen nachfolgenden Sicherheitsmaßnahmen zwangsläufig verloren.
Ist doch auch klar, wenn der Auszahlauslöser im Web logischerweise bis auf deinen TAS einwirken
muss um eine Auszahlung zu veranlassen. Wenn diese Auszahllogik offen liegt, ist das System Kaputt,
egal wieviel hinten dranhängt.
Und genau darum gehts, diese Logik als offenes Script auf dem Server zu *Lagern* ist das Problem.

ps: Es sei denn, du kannst dich an den eigenen Haaren aus dem Brunnen ziehen.