Topic: Für alle diejenigen, die einen sicheren Exchange aufzubauen gedenken... (Read 2440 times)

Nein, das war keine Kritik an dem Thread. Ich fand es aber wichtig, zu betonen, dass man solche Sachen Leuten überlässt, die sich auskennen. Ja, das ist teuer, aber wenn ich Millionenbeträge auf einem Exchange handeln soll, erwarte ich, dass der Betreiber das nötige Geld in die Sicherheit seiner Börse investiert.

Hallo Freyr,


Nach langem hin- und herüberlegen komme ich immernoch nicht drauf, was du damit ausdrücken möchtest.

Angenommen hier gäbe es keinerlei Experten. Dann könntest du dir eine solche Aussage nicht erlauben, weil du in dem Fall auch kein Experte sein könntest.

Allerdings schreibst du eine solche Aussage, weshalb du ein Experte zu sein scheinst. Falls das stimmen sollte, wäre mindestens eine Person hier zugegen, welche sehr wohl kompetenten Rat geben könnte.

Also macht deine obige Aussage in keinem der betrachteten Fälle Sinn, dass solche Themen ausschließlich woanders (wo auch immer das deiner Meinung nach sein sollte) besprochen werden sollten.

Oder was meinst du, wo die heutigen Experten alle herkommen? Die haben allesamt mal unwissend angefangen.

Falls du gemeint haben solltest: "Hey, holt euch Security-Experten für den Aufbau!", dann sei mal kurz angemerkt, dass diese in der Regel enorm viel Geld kosten und dennoch für einen Außenstehenden die konkrete Kompetenz nicht nachprüfbar ist. Also kann man den Exchange auch gleich geschlossen halten und sich für das Geld ein schönes Häuschen in die Pampa stellen.

Zu deiner möglichen Kernaussage bezüglich des vorher Informierens. Wenn ich mir die Ruinen von MtGox so ansehe und dann mal kurz anschaue, was die Ursache für den Bitstamp-Hack gewesen zu sein scheint: Da kommen mir ernsthafte Zweifel, ob sich überhaupt jemand vorher bzgl. Sicherheit informiert zu haben scheint. Besonders bei Stamp habe ich den Eindruck gewonnen, dass da ein Webdesigner mit der gesamten Programmierung beauftragt wurde. Dabei sollte ich vielleicht mal erwähnen, dass Webdesigner in der Branche im Allgemeinen einen sehr schlechten Ruf bzgl. Programmierung mit Sicherheitsanforderungen haben. Das liegt auch daran, weil jeder Mausschubser mit ein bisschen Editorkenntnissen sich in der Regel auch Webdesigner schimpfen darf. Da wird keinerlei tiefergehendes Verständnis der zugrundeliegenden Technologien vorausgesetzt. Mir sind in der Vergangenheit schon einige Exemplare dieser Spezies über den Weg gelaufen, welche schon mit Fragen über die RFCs 768, 791 und 793 hoffnungslos überfordert waren.

Weiterhin schrieb ich oben ausdrücklich:

Weshalb du dich da zu der Aussage:

aufgerufen fühlst, kann ich nicht nachvollziehen. Aus meiner Sicht hatte ich bereits deutlich gemacht, dass das alleine nicht ausreichend ist, um sowas vernünftig aufzuziehen. Aber es sind Tipps, die sich als Best-Practices in meinem Umfeld herauskristallisierten und dementsprechend wertvoll sein können.

Falls du ein Experte sein solltest, dann bringe bitte deine konkrete Kritik im Rahmen der von mir geschilderten Punkte ein. Damit können wir hier durch die Diskussion vielleicht eine Art Katalog zusammenstellen, von dem alle Seiten profitieren würden.

Andernfalls sehe ich auch an diesem Punkt keinerlei Mehrwert für irgendwen.

Gruss,
Bill

Ich will doch stark hoffen, dass jemand, der vor hat einen Exchange aufzumachen, sich nicht über dieses Forum über IT-Sicherheit informiert. Das ist ein Thema für erfahrene Experten, nichts was man mal eben mit ein paar Zeilen Text erklären kann.

Nicht schlecht. Da weiss einer von was er spricht. Oder zumindestens wirkt es nach ausen so

Mache ich vielleicht zum Wochenende hin. Momentan habe ich auch hier schon eine Menge zu tun, da passt mir das Übersetzen eigentlich nicht so ganz in den Kram.

+1

Sehr geil! Poste das nochmal im internationalen Forum!

Es handelt sich hierbei um die Forführung der Beiträge aus diesem Thread.


Falls jemand vorhaben sollte, einen Exchange aufzumachen, möchte ich ein paar kleine Tipps loswerden (nicht vollständig):
1. Überlegt euch vor der Implementation, welche Sachen unbedingt in den Exchange verbaut werden müssen. Je weniger verbaut wird, desto kleiner ist die Angriffsfläche. Je kleiner die Angriffsfläche, desto weniger Informationsgewinn für einen Angreifer.
2. Sucht euch Leute, die schonmal sicherheitskritische Systeme implementierten. Solltet ihr diese nicht finden können, dann achtet darauf, dass ihr möglichst wenige aber dafür für eure Anforderungen am besten geeignete Bibliotheken einbaut. Im Zweifelsfall entscheidet euch für die Bibliothek, welche den größeren Anteil aktiver Entwickler, Tester und dokumentierte Testfälle hat.
3. Wenn ihr Bibliotheken verbaut, so vergesst bitte SaaS (Software as a Service). Ihr baut ein sicherheitskritisches System und eben keine Werbeplattform für externe Dienstleister. Der zusätzliche Code darf aber wegen der besseren Isolier- und Modularisierbarkeit durchaus von einem anderen Server kommen. Dieser sollte aber exakt in derselben Domäne stehen, wie die aufgerufene Seite.
Sinn dahinter: Ein Angreifer erhält so gut wie keine Informationen frei Haus geliefert. Das erschwert die Planung eines Angriffs und erhöht den Aufwand.
4. Misstraut grundsätzlich allen Komponenten, die Teil eures Designs sind. Und jetzt betrachtet euer Vorhaben erneut! Wie schottet ihr die Komponenten gegeneinander ab? In welche Richtung fließen die Daten? In welcher Richtung werden die Steuerungsbefehle gelenkt? Wie sollte es möglichst nicht aussehen, wenn jemand euer Netzwerk übernommen hat? Was würde einem Angreifer so richtig die Suppe versalzen, wenn dieser euer Netzwerk übernommen haben sollte?
5. Investiert mehr als die Hälfte aller eurer Mittel (sowohl Zeit als auch Geld und jegliche andere Ressourcen) in Fehler! D.h. geht davon aus, dass mehrere Tage lang alles schief gehen würde, was nur irgendwie schief gehen kann. Wie sollte das System in der Situation reagieren? Wie schlimm wirken sich Userfehler aus? Was kann durch fehlerhafte Bedienung schief gehen?
Kommt es z.B. durch Bedienfehler zum Datenverlust oder Rechenfehlern, dann wisst ihr bereits ganz genau, dass ihr auf dem Holzweg seid. Testet das System. Rollt nur getestete Komponenten aus und seid euch nicht zu fein dafür, sowohl Unittests als auch Integrationtests einzufordern. Sollte strikt das MVC-Prinzip beibehalten worden sein, dann könnt ihr die kritischen Komponenten fast immer vollautomatisiert testen. Für Integrationstests im Modell eignen sich z.B. expect (Tcl) und pexpect (Python). Greift im Testbetrieb euer eigenes System an! Sabotiert es! Trachtet danach, es zu zerstören! Nutzt Fuzzing (d.h. schmeißt Zufallswerte in die Eingabemasken!). Wenn euer System das alles verdaut, dann kann es in den Produktionsbetrieb gehen und wird ausschließlich netzwerkbasierte DoS-Attacken zu fürchten haben.

Wenn ihr das alles zusammennehmt, kommt ihr zu der goldenen Regel: Designt euer System grundsätzlich als Default-Deny und macht es dennoch fehlertolerant! D.h. das System sollte keinem Client trauen. Ganz besonders dann nicht, falls ein Aufruf nicht ganz sauber sein sollte. Der Server darf möglichst keine Informationen über den internen Aufbau herausgeben. Besonders auf Fehlerfälle darf dieser nach außen nur mit Schweigen und "Business as usual" reagieren.

Verschlüsselung erwähnte ich bisher nicht, weil ich diese als Standard voraussetze. Es versteht sich von selbst, dass diese nur in begründeten Einzelfällen selbst implementiert werden sollte. Das Risiko, Timings nicht richtig gegeneinander abzuwägen oder Speicherbereiche nicht sauber zurückzusetzen ist meistens größer, als die zusätzliche Angriffsfläche durch eine bekannte Bibliothek.