Froschs Blog

Mumble-Server (murmurd) auf Debian Jessie

10. August 2017 um 15:43 Uhr von Atari-Frosch

Weil wir schon grad bei neuen Diensten sind … dieser Tage hatte ich der DinLUG – Dinslakener Linux User Group Hosting zugesagt. Und zwar nicht nur das Blog, sondern auch einen Mumble-Server. Letzteres interessierte mich auch selbst, deshalb habe ich zugesagt, einen solchen zu installieren.

Mumble ist eine freie Sprachkonferenzsoftware, die sich wegen niedriger Latenzzeit und guter Audioqualität für alle Arten von Audio-Konferenzen eignet. Die Verbindungen zwischen Server und Client sind dabei grundsätzlich verschlüsselt.

Die Installation ist weniger kompliziert, als ich befürchtet hatte:

– und dann ist schon alles da. Die Konfiguration erfolgt über eine einzelne Datei, nämlich /etc/murmur-server.ini, die auch nicht sonderlich umfangreich ist. Aber natürlich gibt es auch Fußangeln, sonst wäre ja alles zu einfach.

Zunächst einmal die angesprochene Ini-Datei bzw. deren relevante Teile (Achtung, das hier ist nicht für copy-paste geeignet! Weitere Angaben, die standardmäßig eingetragen sind und die ich weder bespreche noch verändert habe, fehlen hier!):

Ich blieb wie empfohlen bei SQLite, denn viel ist da ja nicht zu verwalten. $HOSTNAME steht da natürlich nicht wirklich, sondern eben der Hostname, auf den der Mumble-Server hören soll.

Das Server-Paßwort müssen Nutzer eingeben, die sich verbinden, ohne bereits registriert zu sein. Bei der Registrierung legt der Mumble-Client dem Server ein Zertifikat vor, anhand dessen der Client dann in Zukunft identifziert wird. Das Server-Paßwort muß dann beim erneuten Verbinden nicht mehr eingegeben werden. Allerdings funktioniert das nur, wenn der Nutzer seinen Usernamen beibehält; der kann am Server auch nicht mehr geändert werden.

Die User-Anzahl sagt natürlich aus, wieviele Nutzer sich gleichzeitig zum Server verbinden können. Ich habe das erstmal auf dem Standard-Wert gelassen.

Die Angabe opusthreshold sagt aus, ab wievielen Clients, die das Audio-Encoding-Format Opus beherrschen, dieses ebenfalls benutzt werden soll. Da Opus inzwischen recht weit verbreitet ist, habe ich hier eingestellt, daß Opus grundsätzlich verwendet werden soll. Erst wenn sich ein Client aufschaltet, der Opus nicht beherrscht, wird auf ein anderes Encoding umgeschaltet.

In einem Mumble-Kanal gibt es immer auch einen Chat. In diesem habe ich mit textmessagelength die Nachrichtenlänge auf 500 Zeichen begrenzt. Da sollen ja keine Romane rein.

logdays=-1 heißt nicht, daß nicht geloggt werden soll, sondern daß nicht zusätzlich in die Datenbank geloggt werden soll. Das normale Server-Log sollte ja genügen.

Die Kanäle werden im Mumble-Client in Form einer Verzeichnisliste angezeigt. Der höchste Kanal oben heißt standardmäßig „Root“. Das ist für viele Leute irreführend – Root steht hier für die „Wurzel“ des Verzeichnisses der Kanäle, ist aber gleichzeitig ein eigener Kanal. Wenn man sich neu zu einem Server verbindet, landet man als erstes in diesem übergeordneten Kanal und kann von dort aus einen anderen Kanal betreten. Das heißt, es hat nichts mit einem User „root“ zu tun, der höhere Rechte hat. Daher wurde dieser Kanal mit registerName in „Empfangshalle“ umbenannt, was die Funktion deutlich macht.

Ein Mumble-Server kann sich selbst in Verzeichnisdienste eintragen, damit er öffentlich gefunden werden kann – wenn man das will. Ich wollte das nicht, deshalb: bonjour=False. Apple Bonjour ist einer dieser Verzeichnisdienste, ich vermute mal, der bekannteste; trotzdem heißt ein „false“ hier, daß gar kein Verzeichnisdienst kontaktiert werden soll. Der Server soll privat bleiben.

Für die Installation hatte ich auch gleich die notwendigen Let's-Encrypt-Zertifikate für die verschlüsselte Kommunikation angefordert. Dazu habe ich den Hostnamen als VHost in den nginx eingetragen und den CertBot darauf angesetzt.

Nebenbei gelernt: CertBot besteht auf einem A-Record. Ein CNAME-Eintrag (Domain-Alias) tut es für ihn nicht – das hatte der Domain-Inhaber nämlich zunächst versucht. Andere Bots für die ACME-Challenge nehmen es damit anscheinend nicht unbedingt so genau. Ich finde es aber in Ordnung, wenigstens da genauer hinzugucken. Schließlich sind die Bedingungen für diese Zertifikate sowieso schon sehr niedrig angesetzt: Es wird ja nur geprüft, ob derjenige, der die Challenge startet, die tatsächliche Gewalt über die Domain und den Webspace hat, aber nicht, wer diese Person ist und ob sie überhaupt berechtigt ist, diese Domain zu benutzen.

Was jetzt noch fehlt und nicht in der Ini-Datei steht, ist das Paßwort für den SuperUser. Also das, was im Linux-System der User „root“ ist. Der wird in Debian so gesetzt:

Hier gehe ich allerdings davon aus, daß nur ein Server gestartet wird – Mumble kann mehrere Server parallel auf derselben Maschine anbieten. Das ist hier nicht nötig. Wenn mehrere Server laufen, hat jeder seinen eigenen SuperUser, und die Nummer des Servers muß hinter dem Paßwort mit angegeben werden. Ansonsten wird der erste angenommen.

Das Paßwort kann auf dieselbe Art nicht nur angelegt, sondern auch jederzeit geändert werden.

Da der Dienst mit dem Aufruf neu gestartet wird, ist es sinnvoll, ihn vorher anzuhalten.

Jetzt kann man sich mit dem Mumble-Server verbinden. Außer dem passenden Client braucht es dazu eine Soundkarte im Rechner, ein Mikrofon und einen Kopfhörer oder Lautsprecher (dazu, warum letzteres unerwünschte Nebenwirkungen haben kann, komme ich noch).

Zunächst einmal verbindet man sich sinnvollerweise als normaler Nutzer und registriert sich, allerdings nur, damit dieser Nutzer überhaupt mal vorhanden ist. Machen kann er nämlich praktisch nix. Dann verbindet man sich neu als SuperUser mit dem vorher angegebenen Paßwort. Der SuperUser kann nun dem ersten Nutzer Admin-Rechte geben und schonmal die ersten Kanäle und Nutzergruppen anlegen. Der SuperUser ist übrigens nicht in der Lage, den Server zu nutzen, er kann nur Einstellungen festlegen: Er ist standardmäßig und unveränderbar auf „stumm“ und „taub“ gestellt. Damit soll der Betreiber des Servers davon abgehalten werden, sich für die normale Teilnahme an einer Konferenz als SuperUser anzumelden. Also wie auf einem Linux-System: Man sollte nur dann root sein, wenn das wirklich nötig ist.

Gestern ging es dann zur praktischen Anwendung.

Auf meinem PC ist der Mumble-Client schon länger eingerichtet, weil ich ja auch das Piraten-Mumble gelegentlich nutze. Nun hatte der Verein Freie Software Freunde gestern Abend eine Besprechung, und daran sollten auch Menschen teilhaben können, die nicht mal eben ins Düsseldorfer Büro fahren können. Also installierte ich den Client auch auf meinem Notebook:

– schloß mein Mikrofon und ein paar alte PC-Boxen an und probierte das damit mal aus. Soundkarten und ihre Mixer können sehr unterschiedlich sein, deshalb wollte ich sicher sein, daß ich am Notebook nicht erst vor Ort herumsuchen muß, wie ich das Mikrofon so aktiviere, daß es auch als Capturing Device benutzt wird.

Solange ich allein auf dem Server war, ging alles. Aber als sich ein zweiter Mensch zum Testen aufschaltete, hatte ich plötzlich ein zeitversetztes Echo meiner eigenen Stimme in den Boxen, und ich verstand erst nicht, wieso. Kaum war der andere Nutzer wieder weg, war auch das Echo weg. Da machte ich mir schon Sorgen, wie das ein paar Stunden später mit diesem und weiteren Teilnehmern der Besprechung funktionieren sollte.

Letztlich hatten wir drei externe Teilnehmer, und im Büro saßen vier bzw. zeitweise fünf Leute. Ich hatte das Mikrofon mitten auf den Tisch gestellt und die beiden Boxen mindestens je einen Meter davon entfernt platziert, damit es keine Rückkopplung gab. Dieses Mikro ist sehr aufnahmefreudig, das könnte man glatt als Wanze einsetzen.

Alle drei externen Teilnehmer hatten früher oder später erklärt, daß es für sie ein Echo gab, sie sich also selbst zeitversetzt nochmal hörten. Außerdem stellten wir fest, daß ein bestimmter externer Teilnehmer A einen anderen bestimmten externen Teilnehmer B mit besonders starkem Echo hörte, während wir im Büro den Teilnehmer B besonders klar und komplett ohne Echo hören konnten.

Schließlich wurde klar: Alle, die mit Lautsprechern statt Kopfhörern arbeiteten, erzeugten Echos. Das betraf natürlich ganz besonders das Büro, wo ich mit meinem sehr aufnahmestarken Mikrofon und den zwei PC-Boxen arbeitete. Das Mikrofon „hörte“ den Output der Boxen und sendete diesen nochmal an den Server – was natürlich darin resultierte, daß alle anderen ein Echo hatten.

Die Boxen waren ja, wie gesagt, etwa einen Meter vom Mikro entfernt. Selbst lokale Teilnehmer, die sich drei Meter vom Mikrofon entfernt aufhielten, konnten von den externen Teilnehmern noch einwandfrei verstanden werden, ohne besonders laut reden zu müssen. Der Output der näher stehenden Boxen wurde damit natürlich erst recht wieder vom Mikrofon erfaßt.

Der Server sendet logischerweise das, was ein Client ihm sendet, nicht wieder an diesen zurück, sondern nur an alle anderen. Schickt aber nun ein Client, weil das Mikrofon den Output der Boxen „hört“, das Ganze nochmal an den Server, kann dieser natürlich nicht erkennen, daß das ursprünglich von ihm selbst kam, und sendet es wieder an alle anderen – die dann ein Echo bekommen, teils von sich selbst und teils von anderen.

Das bei uns im Büro ankommende Echo von anderen Clients mit Lautsprechern dürfte dann allerdings zu leise gewesen sein, um über die Boxen nochmals gehört zu werden. Deswegen hörten wir im Büro nur selten selbst Echos, obwohl wir sicher ebenfalls welche bekamen.

Fazit: Mit Lautsprechern und aufnahmestarkem Mikrofon eine ganze Gruppe mit einem Client ins Mumble zu bringen, ist eher ungünstig und wird immer Echos erzeugen.

Um das zu vermeiden, müßte man bei der Gruppe das Mikrofon sehr weit herunterregeln (oder ein entsprechend weniger aufnahmefreudiges Mikro verwenden) und es dann der jeweiligen Sprecherin in die Hand drücken. Die Sprecherin sollte sich außerdem möglichst weit weg von den Boxen aufhalten. Man ahnt die Kabel-Verwicklungen 😉 – zumal die Kabel von 08/15-Mikrofonen eher selten wirklich lang sind, sondern, wie meines, etwa 1,5 Meter Länge mitbringen.

Die – technisch gesehen – bessere Variante wäre wohl, Besprechungen komplett ins Mumble zu verlegen und zu vermeiden, daß mehrere Teilnehmer über einen einzigen Client angebunden werden, da solche Gruppen immer auf einen Lautsprecher angewiesen sind und naheliegenderweise keinen Kopfhörer benutzen können. Das heißt aber eben auch, daß alle Konferenz-Teilnehmer den Mumble-Client installieren und über eine Soundkarte, ein Mikrofon und Kopfhörer verfügen müßten. Und natürlich über einen Internet-Zugang, der schnell und stabil genug ist.

Heute gab es dann noch eine nette Mail vom Bundesamt für Sicherheit in der Informationstechnik (BSI) mit Umweg über meinen Server-Hoster: Man habe bei einem Scan festgestellt, daß mein Server den Port 5353 offen stehen hätte. Das wäre, ähmja, nicht so gut, und man solle das doch bitte vermeiden.

Der Mumble-Server selbst hat einen völlig anderen Port. Was da offen steht, ist der Port des avahi-daemon. Der wird allerdings gar nicht grundsätzlich vom Mumble-Server benötigt, sondern nur dann, wenn dieser öffentlich sein und in Verzeichnisdienste eingetragen werden soll (das mit dem „bonjour“ in der Ini-Datei). Diese Meldung übernimmt anscheinend nicht der Mumble-Server selbst, sondern eben avahi. Ich guckte mir das mal von außen an:

:~# nmap -p 5353 seelilie.atari-frosch.de

Starting Nmap 6.47 ( http://nmap.org ) at 2017-08-10 13:20 CEST
Nmap scan report for seelilie.atari-frosch.de (176.9.63.237)
Host is up (0.028s latency).
rDNS record for 176.9.63.237: seelilie.atari-frosch.de
PORT     STATE  SERVICE
5353/tcp closed mdns

Closed – das heißt laut Manpage von nmap:

A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.

Der Port wäre also nur erreichbar, wenn sich der Mumble-Server tatsächlich irgendwo eintragen bzw. melden will. Ist er als privat konfiguriert, wie hier, haben der Port und der dahinter stehende Dienst – auch sicherheitstechnisch – überhaupt keine Bedeutung.

Debian auf der einen Seite installiert also als feste Abhängigkeit vom Mumble-Server einen Dienst, der potentiell mißbraucht werden kann, wenn er genutzt wird. Auch dann, wenn er eigentlich gar nicht gebraucht wird. Das Paket wird nicht nur „suggested“, sondern auf jeden Fall nachgezogen.

Das BSI auf der anderen Seite checkt nicht, ob der Dienst tatsächlich aktiv ist, sondern schickt gleich eine Warnung raus, weil der Dienst, wenn er aktiv wäre, mißbraucht werden könnte.

Das ist also gleich von beiden Seiten her etwas ungeschickt …

Immerhin läßt sich der avahi-daemon entfernen, ohne den Mumble-Server wieder mit wegputzen zu wollen:

root@seelilie ~ # apt-get remove avahi-daemon
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  avahi-daemon libnss-mdns
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 457 kB disk space will be freed.
Do you want to continue? [Y/n]

Ich sag mal so: Das wäre … verbesserungswürdig. 😉

History

Dieser Eintrag wurde am 10. August 2017 um 15:43 verfaßt und unter Computer, Internet abgelegt. Sie können alle Antworten auf diesen Eintrag via RSS 2.0 verfolgen. Sie können einen Kommentar hinterlassen oder einen Trackback von Ihrer Website aus setzen.

Schlagwörter: Debian, LetsEncrypt!, Mumble