Mattermost im Tor-Netzwerk hinter einem nginx Reverse-Proxy

Richtig, ich betreibe eine kleine Mattermost-Instanz zum Austausch von Gedanken im Security-Umfeld. Bevor jemand fragt: Wir tragen alle weiße Hüte.

Jedenfalls: Meine Mattermost-Instanz im regulären Internet läuft fein, auch die Tor-Config war rasch erledigt, allerdings bin ich dann über diesen Fehler gestolpert: “Error: Please check connection, Mattermost unreachable. If issue persists, ask administrator to check WebSocket port”

Nach einer kurzen Recherche war das Problem rasch gefunden, mein davor geschnallter Reverse-Proxy (nginx) hatte ein kleines Problem mit den Websockets.

Wie auch immer, hier ist eine funktionierende nginx-Config (Keine Garantien auf irgendwas, das ist ein Experiment.), vielleicht hilft das mal jemandem von euch.

upstream backend-onion {
  # mattermost listening port is 8065 in my config
  server localhost:8065;
  keepalive 32;
}

server {
  # 8080 is the tor hidden service port in my config
  listen 127.0.0.1:8080 default_server;
  server_name localhost;
  port_in_redirect off;

  location = /favicon.ico {
    log_not_found off;
    access_log off;
  }

  location ~ /api/v[0-9]+/(users/)?websocket$ {
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    client_max_body_size 50M;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Frame-Options SAMEORIGIN;
    proxy_set_header CLIENT_HOST $remote_addr;
    proxy_set_header Origin "";
    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    client_body_timeout 60;
    send_timeout 300;
    lingering_timeout 5;
    proxy_connect_timeout 90;
    proxy_send_timeout 300;
    proxy_read_timeout 90s;
    proxy_http_version 1.1;
    proxy_pass http://backend-onion;
  }

  location / {
    client_max_body_size 50M;
    proxy_set_header Connection "";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Frame-Options SAMEORIGIN;
    proxy_buffers 256 16k;
    proxy_buffer_size 16k;
    proxy_read_timeout 600s;
    proxy_cache mattermost_cache;
    proxy_cache_revalidate on;
    proxy_cache_min_uses 2;
    proxy_cache_use_stale timeout;
    proxy_cache_lock on;
    proxy_http_version 1.1;
    proxy_pass http://backend-onion;
  }
}

I’m too old for this shit

A: Wir brauchen XYZ!
B: Als virtuelle Maschine? Oder wie?
A: Nein du Pensionist, das ist sowas von Oldschool. Container!
B: OK, also Container.
A: Aber nicht docker, nein, podman! Viel hipper, funktioniert eh gleich!
B: OK.

$ podman search XYZ
[…]

Tja. Und so scrolle ich jetzt durch 30+ Ergebnisse, mindestens 3 davon mit “official” im Titel und eines ohne “official” im Titel, das ich aber dafür halte. Der Rest ist, hmm, irgendwas?

Da bleib ich lieber Pensionist. Ich mein, nix gegen Container, aber bitte nicht Wild-West Style “Wir installieren halt irgendwas in irgendeiner Version und basteln uns das Zeug zurecht”. Mein Interesse an YAML Config-Files hält sich übrigens auch in sehr sehr engen Grenzen.

robots.txt

Weil ich es eben wieder mit Schaudern feststellen musste: Nein, eine robots.txt ist keine Firewall, an die sich Clients halten müssen. (Es gibt übrigens nicht mal einen RFC dazu.) Es ist vielmehr eine Empfehlung für gutartige Crawler, mehr nicht. Wenn ich in einer robots.txt dann seitenweise(!) Deep-Links sehe, tlw. noch mit Kommentaren, Datum, Versionierung, Usernamen etc. dann hat jemand etwas nicht richtig verstanden. Dies erleichtert nur die Erkundung potentieller Angriffsflächen, was natürlich das genaue Gegenteil des intendierten Ziels war.

Aber geht mal selbst auf Erkundung, natürlich unter strikter Einhaltung sämtlicher rechtlicher Grundlagen!