Wasi weniger kaputtgehen lassen

hacc
#1

Ich mach hier mal einen neuen Thread auf, weil das denk ich auch unabhängig von dem ganzen anderen Zeug relevant ist (außerdem kann ich dann diesen thread auf public stellen :tada:)

Grundsätzliche Ideen, um wasi einigermaßen resilient gegen Angriffe während Events zu machen:

  • Dinge rausnehmen / vordefinieren:
    • Beschreibungstexte nicht als freitext im admin-interface, sondern als ids für texte, die in wasi-web/config schon fest definiert sind (oder ganz entfernen, falls nicht gebraucht/gewünscht)
    • dasselbe für die Messages oben in der Leiste
    • standardzustand für stages auf den stream setzen, damit falls alles schief geht der zumindest noch läuft
    • sicherheitsabfragen einbauen wo noch keine sind; keine links die vom websocket kommen einfach so aufmachen (besonders für die iframe-option vom player)
  • Bessere authentifizierung als nur mit API-key:
    • admins könnten sich über anderen port einloggen
    • der kann dann besser gesichert werden (e.g. nur aus lokalem netz / mit vpn erreichbar), oder irgendwie anders geroutet
  • Rate-limiting und andere dinge gegen d-dos
    • im Server schon implementiert (aber sehr rudimentär, ist einfach ein counter)
    • über nginx / firewall? (kenn mich da nicht aus)
    • wasi verclustern (irgendwie ne lächerliche idee, allerdings für mich evtl. auch sinnvoll um zu lernen wie cluster funktionieren — aber fraglich, ob das zeitnah machbar ist und dann auch gut läuft, weiß davon zu wenig um das wirklich einzuschätzen)
    • Server aufsplitten: einen für claps und einen für die restliche, doch etwas relevantere steuerung, damit wasi noch benutzbar ist auch wenn jemand zuviele claps sendet

Was haltet ihr von den Ideen so? Habe selbst bei einigem auch zu wenig Erfahrung um da sicher zu sein wie gut Dinge gehen bzw. wieviel die dann tatsächlich auch helfen — andersrum, das scheint bei „professionellen“ anbietern ja auch nicht wirklich anders zu sein :see_no_evil:

#2

Ich glaube an sich müssen wir wie bei Livestreams selbst einmal pauschal davon ausgehen, dass Wasi kaputt gehen wird - auf die eine oder andere Art und Weise - und insbesondere immer anders als erwartet.

Ich persönlich würde deswegen eine prioritätenliste schreiben, was denn am Wichtigsten für das „Funktionieren“ von Wasi ist und was weniger wichtig ist - und daran dann orientieren, wie man was abscihern kann.
(Es doppelt sich viel mit dem von dir @stuebinm - ich wollte es aber noch einmal anders aufreihen)

  1. Video-Stream muss immer default sein An sich sollte mit komplett kaputtem backend trotzdem der video-stream angezeigt werden (meine persönliche Meinung) - es wäre schade, wenn mitten im Stream obwohl dieser noch läuft ein „Technical Difficulties“ das Livebild unnötig unterbricht - oder man das beim aufrufen der Seite als einziges sieht.
  2. Chat/Iframe - noch bessere Kommunikationsmöglichkeit als irgendwelche Banner-benachrichtigungen (natürlich nur sofern vorhanden)
  3. Admin-Panel - Ohne Admin Panel wird der ganze Rest ein bisschen schwer…
  4. Textbanner Danach würde ich die Banner-Benachrichtigungen ansetzen, die als glaube ich einfachste kommunikationsmöglichkeit genutzt werden sollten.
  5. Stream-Schalterei
  6. Beschreibung
  7. Zuschauer & geklatsche

Das ist erstmal ganz unabhängig von der Umsetzung.
Grundsätzlich sollte alles erstmal gegen einen Überlauf/DDOS geschützt sein. Das ist glaube ich jedoch durch die statische Natur der Seite gut gewährleistet, das einfachste die Seite tot zu bekommen wäre einfach die Bandbreite zuzuballern - dagegen könnte man ein Load-Balancing einsetzen, Cloudflare oder vor allem auch kostenpflichtige Anbieter haben da einige Angebote.
Bei CF ist oft der Einwand, dass das ja zu spät erst einsetzt - man könnte entgegnen, dass man ja beim Stream daneben sitzt und das manuell aktivieren kann.
Alles weitere muss vermutlich durch gescheites Loadbalancing und vielleicht auch filtering gehandelt werden - das ist ja leider kein Traffic, der einfach „pauschal“ geblockt werden kann - es gibt ja Menschen die einfach viel klatschen etc.
Vielleicht gibt es da auch intelligentes IP-Blocking, wenn zu viele requests auf einmal kommen oder so.

Für die Authentifizierung würde ich fast sagen, dass solange wir die Admins sind auch ein ssh-tunnel und port binding klappen würde. - Das alles zusammen mit nur key-basierter authentifizierung auf serverseite sollte sicher sein.

Als drittes steht ja die kommunikation zwischen backend und frontend. Ich weiß nicht, inwiefern websockets selbst schon sicher sind, ansonsten würde ich vorschlagen für nachrichten, beschreibungstexte etc eine asymmetrische Verschlüsselung drüberzupacken, so viel mehr rechenaufwand ist das auch wieder nicht.

#3

Ich bin mir nicht sicher, ob ich stream-umschalten erst als fünftes einordnen würde, weil das ja doch das event auch kaputtmachen kann oder zumindest menschen dazu zwingen kann, die seite neu zu laden (e.g. falls zwischendurch mal ne pausenslide war) — das ist natürlich auch vom event abhängig, aber wasi soll ja allgemein möglichst gut funktionieren, nicht nur für ein spezielles event.

Naja, es gibt denk ich doch ein limit wie oft menschen dauerhaft auf einen button drücken wollen; irgendwann wird das auch langweilig. Intelligente IP-blocking etc. weiß ich nicht was es da gibt — wenn müsste das aber wohl entweder in wasi implementiert werden (aufwendig, potentiell fehleranfällig) — oder das geht über nginx/iptables oder so (wenig ahnung von, klingt aber vertrauenswürdiger).

ssh-tunneling als sicherheit klingt eigentlich nicht doof — dann müssten wir halt schaun, dass alle lokal bei sich ne kopie des host-panels haben. Oder jemand schreibt einen wasi-controller für die shell :tada: (aber $zeit)

Websockets sind an sich tcp-ports die zweckendfremdet wurden; unsere sind auch schon verschlüsselt. Ich glaub um die Verbindung müssen wir uns da fast weniger sorgen machen (@hexchen widersprich mir gerne, du hast da denk ich mehr ahnung); ich versteh grad allerdings nicht wirklich, wie du da asymmetrisch dinge verschlüsseln willst — soll jeder client spontan sein eigenes Paar Schlüssel generieren? Das wäre doch sehr aufwendig. Evtl. ließen sich Dinge zumindest mit nem admin-key signieren oder so — weiß da aber auch nicht, wie einfach oder schwer das umzusetzen wäre (wobei ich mal vermute, dass schon irgendwer ein cargo-packet dafür geschrieben haben wird)

#4

du kannst einfach den webserver nur an localhost erlauben und dann reintunneln und localhost öffnen (port binden und so) - braucht also nicht jeder einzelne das hostpanel lokal.

Was ich mir gedacht habe ist, dass es so ähnlich wie bei ssl (wenn ichs richtig verstanden habe) ist, dass wir einen schlüssel ins js reinkleben der dadurch implizit richtig ist und mit dem dann nachichten vom server checken. - client to server kommunikation sollte woanders gefiltert werden.

#5

Stimmt, wenn man schon tunnelt lässt sich auch gleich der webserver tunneln — wobei man dann halt etwas aufpassen muss, weil zwei webserver (je nach „paranoia-level“ wirklich zwei getrennte oder eine große config)

Bei deiner idee zu asymetrischer verschlüsselung weiß ich nicht, was die bringt — um nachrichten vom server zu signieren gibts doch schon https bzw. wss? (außer irgendwer klaut das cert oder hackt die CA — aber damit rechne ich erstmal nicht) Oder gibt es irgendwelche fälle unter denen tls kaputt geht von denen ich (noch) nichts weiß?

#6

Nee, war nur ein unsinniger gedanke von mir um zu spät nachts :see_no_evil:

#7

Update: wasi nimmt sich jetzt zwei bind-addressen, eine für zuschauende (standard ist 0.0.0.0:9000) und eine für admin-interaktionen (standard ist 127.0.0.1:9001). Admins müssen sich trotzdem noch erst per API-Key identifizieren.

Besonders viel geändert hab ich an dem code allerdings nicht; je nach eingehender adresse wird einfach nur ein bool anders gesetzt, und dann bei eingehenden nachrichten ne andere funktion aufgerufen — i.e. wenn man etwas binary exploitation machen will, muss man „nur“ dieses eine bool erwischen. Angeblich ist das bei rust ja eher schwierig, aber gegeben $zeit würd ich mich trotzdem nochmal hinsetzen und das dinge etwas grundlegender umstrukturieren, auch weil jetzt manche datenstrukturen nur noch mit viel phantasie wirklich sowas wie sinn ergeben (warum sind admins im selben array wie zuschauer*innen?).

#8

Nochmal ein Changelog:

  • unterschiedliche ports sind jetzt auch in wasi-web implementiert
  • es lassen sich standardbeschreibungen setzen
  • es lässt sich verbieten, dass diese vom server verändert werden können
  • der server ließt endlich die standard-stage covers aus der config und hat da keinen hardgecodeten dateipfad mehr drin :tada:
1 Like
#9

Dinge, die ich nach dem Event heute gerne mal machen würde:

  • multithreading testen
  • gedanken über proxy/cluster/allgemein mehr als eine wasi-instanz für ein event machen
  • mehr monitoring/logs?
  • nixpackage
1 Like