Docker & QEMU auf einem Rechner

Problem : Ich habe Docker und QEMU auf einem Rechner laufen. Nach der Docker Installation war es der virtuellen Maschine in QEMU nicht mehr möglich ins Internet zu zugreifen.

Lösung :
In meinem Fall waren die Default Einstellungen der Docker-CE Installation Schuld. Durch das korrigieren der IP-Tables konnte ich das Problem in meinem Fall beheben.
iptables -A FORWARD -i br1 -o br1 -j ACCEPT
Der Fehler tritt auch manchmal auf wenn der Linux Server in QEMU installiert ist und die lokale Firewall Einstellung das forwarding nicht zulässt.

Websockets mit Apache hinter haproxy

Ich hab hier eine Anwendung die WebSocket verwendet und im HA Umfeld läuft (haproxy). Leider benötigt diese Anwendung auch Sessions (sticky) deswegen musste ich ein wenig basteln ;-) Bei mir läuft eine node.js Anwendung hinter dem haproxy , für andere Fälle muss man vermutlich noch etwas mit der Konfiguration spielen.

haproxy config websockets
Erstmal habe ich in der vhost des Apaches dafür gesorgt das ws auf den richtigen Server geleitet wird.

vhost
   RewriteEngine On
   RewriteCond %{HTTP:Connection} Upgrade [NC]
   RewriteCond %{HTTP:Upgrade} websocket [NC]
   RewriteRule /demoapp/(.*) ws://demo-srv-01:3030/$1 [P,L]

   RedirectMatch           ^/demoapp$   TARGET-URL/demoapp/
   ProxyPass               /demoapp/    http://demo-srv-01:3030/
   ProxyPassReverse        /demoapp/    http://demo-srv-01:3030/

Dann hab ich die haproxy Konfiguration auf die Anwendung zugeschnitten.

haproxy
listen demoapp:3030
  bind *:3030
  # EIO ist immer gesetzt wenn über Websocket
  acl IsStatus urlp(EIO) 3
  use_backend ws_demoapp if IsStatus
  use_backend default if !IsStatus

backend ws_demoapp
  mode http
  # eventuell gesetzte Header löschen
  rspdel ^Server:.*
  rspdel ^X-Powered-By:.*
  # und durch Server demoapp Header ersetzen
  rspadd Server:\ demoapp
  # diese Seite muss HTTP-Status 200 liefern damit der HA erkennt das alles ok ist
  option httpchk HEAD /lbhealth
  # check auf Status wenn der 200 ist ist alles ok
  http-check expect status 200
  # using the `io` cookie set upon handshake
  cookie io prefix indirect nocache
  # Server Endpunkte
  server wsdemoapp01 ws-demo-srv-01:8200 check cookie monitor01
  server wsdemoapp02 ws-demo-srv-02:8200 check cookie monitor02

backend default
  mode http
  # eventuell gesetzte Header löschen
  rspdel ^Server:.*
  rspdel ^X-Powered-By:.*
  # und durch Server demoapp Header ersetzen
  rspadd Server:\ demoapp
  # Server Endpunkte wird normal gebalancet
  balance leastconn
  server node01 ws-demo-srv-01:80 check cookie node01
  server node02 ws-demo-srv-02:80 check cookie node02
Quellen & Info :
https://de.wikipedia.org/wiki/WebSocket
https://load-balancer.info/themen/sticky-session-load-balancing/
https://nodejs.org/en/about/
https://www.haproxy.org/#desc
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

SSH : Tunneln zu Maschine hinter Jumphost

Da ich mir das nie merken kann schreib ich das hier mal auf ;-)
Ich möchte die Status Seite eines haproxys in einem Netz anzeigen das nur über einen Jumphost erreichbar ist. Dafür braucht man 2 Tunnel einen auf den Jumphost und dann von Jumphost auf das Zielsystem. Der Jumphost und das Zielsystem müssen mit Key verbunden sein das ein Tunnel möglich ist. ( SSH Login mit authorized_keys )
ssh -L 9090:localhost:9090 USERNAME@JUMPHOST -i SSHKEY ssh -L 9090:localhost:9090 -N USERNAME@TARGETSYSTEM

Nextcloud 14 : mod_security2 Id's

Meine Nextcloud 14 hat nach dem Update nicht richtig funktioniert. Filetree hat sich nich aufgebaut caldav hat nicht mehr funktioniert. Nachdem ich in der VHost folgenden Eintrag hinzugefügt habe hat wieder alles funktioniert.
<IfModule mod_security2.c>
    # Nextcloud
    SecRuleRemoveById 949110 911100 920420
</IfModule>

Grafana : Nach Update keinen Zugriff auf Datenquelle

So nun ist es auch mir mal passiert, nach einem Update von Debian 8.11 auf 9.5 hat das installierte Grafana keinen Zugriff mehr auf die influxdb mehr erhalten. Bei mir war mod_security2 der Grund. Nachdem ich eine neue Regel in die VHost eingetragen habe hat wieder alles funktioniert. Mein Grafana läuft hinter einem SSL Proxy.

Ich hab diese Fehlermeldung erhalten:
Title : 403 Forbidden
Message : You don't have permission to access /grafana/api/datasources/1 on this server.
Konfig in den VHost eintragen.

mod_security2
das sind noch nicht alle id's bin noch am sammeln ;-)
man kann die SecRules auch auf eine Location deaktivieren das ist der schnellere aber auch unsichere Weg

mod_security2_1
modsecurity
Alternativ dazu könnte man das Modul auch deaktivieren, aber Sicherheit geht vor ;-) Für einen Test kann man das mit dem folgenden Befehl erreichen.
a2dismod security2 ; systemctl restart apache2

“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz