Mein@Gehirn-Mag.net
  • RSS
  • RSS
  • CodePen
  • GitLab
  • Icinga Exchange
  • Printables
Gehirn-Mag.Net
  • Startseite
  • Über mich
  • Blog
  • Datenschutz
  • Impressum
Seite wählen

fail2ban für Jitsi

von Steffen | Aug. 7, 2020 | Linux, Tips und Tricks | 0 Kommentare

Jitsi Sicherheit

Neulich kam die Frage in Folge des Beitrags fail2ban: Übersichtlich? Übersichtlich! wie man eigentlich fail2ban für Jitsi (bzw. prosody) einrichtet. Die Frage ist nicht nur in Zeiten von Corona berechtigt – hat jedoch derzeit gerade aufgrund der häufig genutzten Webmeetings eine ganz besondere Wichtigkeit erlangt. Nun gut, dann mal eben rasch drauf geschaut.

Das ganze läuft bei mir hier auf Ubuntu 20.04. Ggf. muss man den ein oder anderen Pfad anpassen. Wie gehabt ändert das aber nichts am Wesen der ganzen Sache hier.

Somit Datei Nummer 1 die bearbeitet werden muss: /etc/fail2ban/filter.d/prosody-auth.local

[Definition]
failregex = Failed authentication attempt \(not-authorized\) for user .* from IP: <HOST>
ignoreregex =

Datei Nummer 2 ist /etc/fail2ban/jail.d/prosody.local

# Prosody/Jitsi
[prosody]
enabled = true
filter = prosody-auth
logpath = /var/log/prosody/prosody.log
maxretry = 5

Fail2ban ist soweit eigentlich ganz übersichtlich. Der Filter besteht lediglich aus einem einfachen regulären Ausdruck, die Definition des Jails führt wie gewohnt Filter und Logdatei zusammen. Die meisten sonst noch benötigten Einstellungen stammen bei mir aus der globalen Vorlage.

Fehlt noch einer: Jitsi bzw. prosody muss man dazu bringen genau diese Informationen tatsächlich ins Log zu schreiben. Das tut er normalerweise nicht. Somit Datei Nummer 3 die zu bearbeiten ist: /etc/prosody/prosody.cfg.lua

modules_enabled = {
  -- Hier die ganzen Module wie gehabt stehen lassen und lediglich dafür sorgen, dass folgende Zeile darin zusätzlich vorkommt:
  "log_auth";
}

Das war es. Nachdem beide Dienste neu gestartet wurden bzw. Ihre Konfig neu eingelesen haben schreibt Jitsi bzw. prosody in einem für fail2ban verständlichen Format auf sobald die Authentifizierung des Moderators gescheitert ist. Der Rest ist gewohnt leichtes Spiel für fail2ban.

Wie ich auf die Idee gekommen bin dies auf diese Art und Weise zu lösen? Naja, steht im Handbuch von prosody drin: https://modules.prosody.im/mod_log_auth.html. Hier sollte man halt darauf achten, dass das für prosody ohne Jitsi gilt. Ggf. muss man die Ports anpassen. Oder so wie ich in der [DEFAULT] Sektion banaction = route setzen. Dann sind die Ports egal 😉

About Steffen

Steffen | Website

Kommentar absenden Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • Allgemein (8)
  • Backup (1)
  • DNS (3)
  • Email (8)
    • Kopano (1)
  • Freizeit (1)
    • GPS (1)
  • Gestern war alles besser (7)
  • LDAP (2)
  • Linux (27)
    • Tips und Tricks (24)
  • Monitoring (9)
  • Netzwerk (6)
    • Firewall (1)
      • OPNsense (1)
    • IPv6 (1)
  • Nextcloud (3)
  • PV (1)
  • Seltene Wunder (13)
  • SNMP (2)
  • Spaß (2)
  • Uncategorized (1)
  • Verschlüsselung (6)
  • Virtualisierung (2)
    • VirtualBox (1)
    • VMware (1)
      • ESXi (1)
  • VPN (1)
    • OpenVPN (1)
  • Webdesign (3)
  • Webhosting (2)
    • apache (2)
  • Werbung (16)

Schlagwörter

*nix apache Backup Beatles Bind check_by_ssh check_nrpe cron dig DNS Email fail2ban failover Firewall gut zu wissen HC1 https Icinga2 ipv6 Jitsi LetsEncrypt Lied Linux MIB Migration Monitoring Nagios Nextcloud nrpe ntp postfix QR Sicherheit SNMP Spaß ssh SSL TLS Update Verschlüsselung VirtualBox VDI loop mount Wildcard Will-ich-auch WordPress yesterday

Archiv

  • RSS
Powered by Schoch-IT.Solutions