Mumble-Server vor DDoS-Angriffen schützen

Ein Mumble-Server ist die schlankeste Art, eine Gruppe ohne fremden Dienst sprechen zu lassen: quelloffen, selbst gehostet, ein einziger Port, keine Lizenzdatei und kein Konto bei irgendwem. Genau diese Schlichtheit hat eine Kehrseite, die kaum jemand kennt. Auf Port 64738 UDP beantwortet der Server eine zwölf Byte kleine Anfrage, die niemand anmelden muss, mit vierundzwanzig Byte Serverdetails. Die Absenderadresse dieser Anfrage ist frei fälschbar. Wer diese Antwort nicht abschaltet, betreibt einen Reflektor, den Fremde gegen Fremde richten.

Dieser Beitrag erklärt, wie ein Mumble-Server technisch aufgebaut ist, welche Angriffsarten ihn wirklich treffen, welche Zeilen in der Konfigurationsdatei etwas bewirken und wo jede Maßnahme auf dem Server endet. Die Befehle sind für Debian 12, Debian 13, Ubuntu 22.04 LTS und Ubuntu 24.04 LTS geschrieben. Wo root nötig ist, steht es dabei. Alle genannten Einstellungen stammen aus der mitgelieferten Konfigurationsdatei des Mumble-Servers, nicht aus Foren.

Warum ein Mumble-Server angegriffen wird

Ein Mumble-Server wird aus drei Gründen zum Ziel, und keiner davon hat mit der Größe des Projekts zu tun.

Erstens ist Sprache in Echtzeit unbarmherzig. Eine Webseite mit zwei Prozent Paketverlust bemerkt niemand, weil TCP die fehlenden Segmente noch einmal sendet. Sprache kennt keine Wiederholung: Ein verlorenes Paket ist eine Lücke im Ton, und die hört jeder im Kanal sofort. Ein Angriff muss die Leitung also nicht sättigen, um sie unbrauchbar zu machen. Zwei Prozent Verlust reichen.

Zweitens ist der Sprachweg verbindungslos. Mumble überträgt Sprache über UDP. Es gibt keinen Handschlag, bevor das erste Paket ankommt, und die Absenderadresse lässt sich in jedem Paket frei eintragen. Der Server muss jedes ankommende Paket erst ansehen, um es verwerfen zu können. Der Angreifer braucht weder Zugang noch Passwort, nur die IP-Adresse und die Portnummer. Was dabei technisch passiert, beschreibt der Beitrag Was ist ein DDoS-Angriff?.

Drittens antwortet der Server ungefragt mit Auskünften über sich selbst. Das ist der Punkt, der Mumble von den meisten Sprachdiensten unterscheidet, und er bekommt weiter unten einen eigenen Abschnitt. Kurz gefasst: Der Server verrät ohne Anmeldung seine Version, die Zahl der verbundenen Benutzer, die Obergrenze und die erlaubte Bandbreite je Benutzer. Das ist als Komfortfunktion gedacht und wirkt als Einladung.

Mumble, Murmur und mumble-server: welcher Name gerade gilt

Der Client heißt seit jeher Mumble. Der Serverteil hieß lange Murmur, das Programm murmurd, die Konfigurationsdatei murmur.ini. Seit der Umbenennung heißt der Serverteil schlicht Mumble Server, das Programm mumble-server und die Konfigurationsdatei mumble-server.ini. Beide Schreibweisen sind im Umlauf, weil ältere stabile Linux-Veröffentlichungen noch die alte Fassung ausliefern.

Die Namen der Einstellungen innerhalb der Datei sind von der Umbenennung nicht betroffen. allowping, bandwidth, users und serverpassword heißen in beiden Fassungen gleich. Was sich geändert hat, sind Dateiname, Programmname und Ablageort. Der Dienstname ist in beiden Fällen mumble-server, deshalb funktioniert systemctl restart mumble-server auf allen vier hier behandelten Systemen.

Die Ports, um die es tatsächlich geht

Mumble ist in diesem Punkt angenehm übersichtlich: Ein einziger Port, 64738, trägt den gesamten Dienst, und zwar gleichzeitig über TCP und über UDP. Die Kommentarzeile der Konfigurationsdatei sagt das wörtlich: "Port to bind TCP and UDP sockets to."

Die wichtigste Zeile dieser Tabelle: Aus dem Internet erreichbar sein müssen 64738/TCP und 64738/UDP, mehr nicht. Die Ice-Schnittstelle gehört nicht ins Netz, und sie steht ab Werk auch nicht dort. Prüfen Sie es trotzdem, siehe weiter unten.

Warum beide Protokolle offen sein müssen

Die Arbeitsteilung ist klar geschnitten. TCP trägt die Steuerung, UDP trägt die Sprache. Über die TCP-Verbindung laufen der TLS-Handschlag, die Anmeldung, die Kanalstruktur, die Berechtigungen, der Text-Chat und die Dateiübertragung. Diese Verbindung wird beim Verbinden aufgebaut und bleibt für die gesamte Sitzung bestehen. Über UDP laufen die Sprachpakete, verschlüsselt und ohne Empfangsbestätigung, weil eine verspätete Empfangsbestätigung bei Sprache wertlos ist.

Wird 64738/UDP blockiert, ist der Server nicht tot, sondern langsam. Der Mumble-Client bemerkt, dass über UDP nichts zurückkommt, und schiebt die Sprache dann durch die bereits bestehende TCP-Steuerverbindung. Der Client trifft diese Entscheidung nach einer Wartezeit in der Größenordnung von zwanzig Sekunden nach dem Aufbau der Verschlüsselung, wenn bis dahin kein einziges UDP-Paket sauber entschlüsselt werden konnte. Zurück auf UDP wechselt er erst, wenn wieder mehrere UDP-Pakete in beide Richtungen ankommen.

Das Ergebnis dieses Rückfalls hört man. Sprache über TCP bedeutet Empfangsbestätigungen, Neuübertragung verlorener Segmente und Stauvermeidung. Ein einzelnes verlorenes Segment hält die nachfolgenden auf, bis es wiederholt wurde. Aus einem kurzen Knacken wird eine spürbare Verzögerung, die bei schlechter Strecke auf mehrere hundert Millisekunden anwächst. Wer UDP zumauert, um einen Angriff loszuwerden, tauscht einen Ausfall gegen einen dauerhaft schlechten Klang. Das ist in einer Notlage für eine halbe Stunde vertretbar und als Dauerzustand keine Lösung.

Die Ping-Antwort auf 64738 UDP: der Vektor, den kaum jemand kennt

Das ist der Kern dieses Beitrags. Ein Mumble-Server beantwortet auf dem UDP-Port eine unverschlüsselte Anfrage, die keinerlei Anmeldung erfordert, mit einem Datensatz über sich selbst. Der Zweck ist harmlos: Der Verbindungsdialog des Clients soll vor dem Verbinden anzeigen, wie viele Leute gerade da sind und wie schnell der Server antwortet. Dafür sendet der Client ein winziges Paket und misst, wie lange die Antwort braucht.

Die Kommentarzeile in der Konfigurationsdatei benennt die Folge ohne Umschweife. Sinngemäß steht dort: Die Einstellung auf true legt die aktuelle Benutzerzahl, die Obergrenze für Benutzer und die maximale Bandbreite je Client gegenüber nicht angemeldeten Anfragenden offen, und im Mumble-Client werden diese Angaben im Verbindungsdialog angezeigt. Der Vorgabewert ist true.

Was in den 12 Byte hin und in den 24 Byte zurück steht

Beide Pakete haben eine feste Größe. Das macht die Rechnung einfach und nachprüfbar.

Die acht Byte Vorgangsnummer sind der Grund, warum die Sache funktioniert: Der Server schickt sie unverändert zurück, damit der Client Antwort und Anfrage einander zuordnen und daraus die Laufzeit berechnen kann. Für den Server ist die Nummer bedeutungslos. Er prüft nichts, er merkt sich nichts, er antwortet einfach an die Adresse, die im Paket steht.

Neuere Mumble-Versionen haben das UDP-Protokoll auf ein moderneres Format umgestellt. Das alte Paar aus 12 und 24 Byte wird aus Kompatibilitätsgründen weiterhin verstanden und beantwortet, die Abwärtskompatibilität ist im Quelltext ausdrücklich vorgesehen. Die Umstellung nimmt Ihnen die Angriffsfläche also nicht ab.

Der Verstärkungsfaktor, ehrlich gerechnet

Der Bandwidth Amplification Factor, kurz BAF, ist das Verhältnis zwischen der Nutzlast der Antwort und der Nutzlast der Anfrage. Bei Mumble sind das 24 geteilt durch 12, also Faktor 2. Rechnet man das vollständige IPv4-Paket, kommen auf beiden Seiten 20 Byte IP-Kopf und 8 Byte UDP-Kopf dazu: 40 Byte hin, 52 Byte zurück, Faktor 1,3.

Damit steht Mumble am unteren Ende der Skala. Die Referenzliste der Branche ist die Warnmeldung TA14-017A von US-CERT beziehungsweise CISA, und dort stehen ganz andere Zahlen. Zum Vergleich, die fremden Werte stammen aus dieser Meldung, der Wert für Mumble aus der obigen Rechnung:

Wer daraus schließt, die Sache sei harmlos, misst am falschen Maß. Mumble ist kein Bandbreitenverstärker, sondern ein Paketratenreflektor. Das ist ein Unterschied mit Folgen.

Rechnen Sie mit. Ein Angreifer mit einer eigenen Anbindung von 1 Gbit/s bringt bei kleinstmöglichen Paketen rund 1,49 Millionen Pakete pro Sekunde auf die Leitung. Jede dieser Anfragen erzeugt bei einem offenen Mumble-Server genau ein Antwortpaket. Beim Opfer kommen also rund 1,49 Millionen Pakete pro Sekunde an, verteilt auf so viele Quelladressen, wie der Angreifer Mumble-Server gefunden hat. In Bit gerechnet ist das kaum mehr, als der Angreifer selbst gesendet hat. In Paketen gerechnet ist es alles, was er senden konnte.

Paketrate ist die Größe, an der Netzwerkkarten, Zustandstabellen und Firewalls zuerst scheitern, nicht Bandbreite. Dazu kommt der eigentliche Gewinn für den Angreifer: Der Verkehr trifft beim Opfer von echten, betriebenen Servern mit sauberen IP-Adressen ein. Eine Sperrliste nach Quelladresse sperrt dann reihenweise unbeteiligte Mumble-Betreiber aus, und der Angreifer selbst bleibt unsichtbar.

Warum das auch den Reflektor selbst trifft

Es geht nicht nur um Fremde. Jede beantwortete Ping-Anfrage kostet Ihren eigenen Server einen Systemaufruf, ein ausgehendes Paket und einen Anteil Ihrer ausgehenden Paketrate. Wird Ihr Server in eine Reflektionswelle eingespannt, sendet er über Stunden Pakete an ein Opfer, das Sie nicht kennen. Drei Dinge folgen daraus: Ihre eigene Sprachqualität leidet, weil die Netzwerkkarte beschäftigt ist, Ihr Anbieter sieht einen auffälligen ausgehenden Paketstrom, und Ihre IP-Adresse landet auf Listen, aus denen sie schwer wieder herauskommt.

Und es gibt eine angenehme Eigenheit der Reflektion, die man kennen sollte, weil sie die Verteidigung leicht macht: Bei einem Missbrauch als Reflektor tragen alle gefälschten Anfragen dieselbe Absenderadresse, nämlich die des Opfers. Eine Ratenbegrenzung je Quelladresse ist deshalb gegen den Missbrauch Ihres Servers als Reflektor sehr wirksam, während sie gegen einen Angriff auf Ihren Server kaum etwas ausrichtet, weil dort die Absenderadresse in jedem Paket neu gewürfelt wird. Dieselbe Regel, zwei völlig verschiedene Wirkungsgrade.

Was allowping=false bewirkt und was Sie dafür verlieren

Die Einstellung heißt allowping und steht in der Konfigurationsdatei des Servers. Der Vorgabewert ist true. Setzen Sie sie auf false:

allowping=false

Danach den Dienst neu starten:

systemctl restart mumble-server

Das bewirkt es: Der Server beantwortet die unverschlüsselte Ping-Anfrage nicht mehr. Die Abfrage läuft ins Leere, es geht kein Paket zurück, Ihr Server steht als Reflektor nicht mehr zur Verfügung.

Das kostet es: Im Verbindungsdialog des Mumble-Clients bleiben die Felder leer. Keine Latenz, keine Benutzerzahl, keine Obergrenze, keine Bandbreitenangabe. Wer Ihren Server als Lesezeichen hat, sieht nicht mehr, ob gerade jemand da ist, und muss sich verbinden, um es zu erfahren. Steht Ihr Server im öffentlichen Verzeichnis, wirkt der Eintrag dort leer und tot.

Die Abwägung ist damit ehrlich beschreibbar. Für einen geschlossenen Kreis, der sich ohnehin über Absprache verbindet, ist der Verlust gleich null und der Gewinn real. Für einen offenen Server, der neue Leute über das Verzeichnis gewinnen will, ist die leere Anzeige ein echter Nachteil. In diesem Fall lassen Sie allowping an und begrenzen stattdessen die Rate der Ping-Anfragen im Paketfilter, wie weiter unten gezeigt.

Eine Nebenwirkung, die Sie nach der Umstellung einmal nachprüfen sollten: Die Einstellung betrifft denselben Ping-Mechanismus, an dem der Client seinen UDP-Weg erkennt. Angemeldete Clients senden ihre Laufzeitmessung verschlüsselt über die bestehende Sitzung, und diese Pakete werden nach der Entschlüsselung beantwortet, also unabhängig von allowping. Prüfen Sie es trotzdem einmal im laufenden Betrieb: Sprechen Sie mit zwei Leuten in einen Kanal und sehen Sie im Client nach, ob die Verbindung weiterhin als UDP-Verbindung geführt wird. Fünf Minuten Nachprüfen sind billiger als eine Woche schlechter Klang, den niemand einer Konfigurationsänderung zuordnet.

Die übrigen Angriffsarten gegen einen Mumble-Server

Die Ping-Antwort ist die Besonderheit, aber nicht die einzige Angriffsfläche. Drei weitere Muster treffen einen Mumble-Server regelmäßig.

UDP-Flut direkt auf 64738

Der plumpeste Fall: möglichst viele UDP-Pakete beliebigen Inhalts an den Sprachport. Der Server muss jedes davon annehmen, die Absenderadresse in seiner Tabelle der bekannten Clients nachschlagen, und wenn sie dort nicht steht, prüfen, ob es sich um eine Ping-Anfrage handelt. Erst danach kann er es verwerfen. Jeder dieser Schritte ist billig, aber keiner ist gratis, und die Rechnung wird mit der Paketrate multipliziert.

Die Wirkung setzt lange vor der Überlastung der CPU ein. Sobald die ankommende Paketrate die Verarbeitungskette sättigt, verwirft der Kernel Pakete ohne Ansehen des Inhalts, und darunter sind die Sprachpakete Ihrer Leute. Im Kanal hört sich das nicht nach Verzögerung an, sondern nach Aussetzern: abgehackte Silben, Roboterstimme, plötzliche Stille bei laufender Verbindung.

Verbindungsflut auf den TCP-Port

Der zweite Fall zielt auf 64738/TCP und ist deutlich sparsamer. Jede Verbindung zum Steuerkanal beginnt mit einem vollständigen TLS-Handschlag. Der Angreifer muss dafür kaum rechnen, wenn er den Handschlag nach dem ersten Schritt abbricht, Ihr Server hat seinen Teil da aber schon geleistet.

Das ist der asymmetrische Klassiker: Ein Paket vom Angreifer, ein Schlüsselvorgang bei Ihnen. Ein einzelner Rechner mit einem normalen Anschluss kann damit einen Mumble-Server beschäftigen, ohne auch nur in die Nähe einer Bandbreitengrenze zu kommen. Gegen genau dieses Muster bringt Mumble ab Werk eine Bremse mit, die weiter unten beschrieben ist.

Anmeldeflut und warum die Zertifikatsprüfung Rechenzeit kostet

Der teuerste Fall ist die Anmeldeflut. Mumble sichert den Steuerkanal grundsätzlich mit TLS ab, und der Client weist sich dabei mit einem eigenen Zertifikat aus, das er sich beim ersten Start selbst erzeugt. Für den Server bedeutet jede Verbindung: Handschlag aushandeln, eigenes Zertifikat vorzeigen, das Zertifikat der Gegenseite entgegennehmen und prüfen, Sitzungsschlüssel ableiten. Das sind asymmetrische Rechenoperationen, und die sind um Größenordnungen teurer als das Verwerfen eines UDP-Pakets.

Verschärfend kommt bei registrierten Benutzern die Passwortprüfung dazu. Der Server leitet Passwörter absichtlich aufwendig ab, mit PBKDF2 und einer Zahl von Durchläufen, die er ab Werk selbst einmisst. Das ist gegen das Durchprobieren gestohlener Passwortlisten genau richtig und wirkt bei einer Anmeldeflut gegen Sie: Jeder Anmeldeversuch mit falschem Passwort kostet Sie die volle Ableitung. In der Konfigurationsdatei gibt es dafür eine Einstellung, die die automatische Einmessung überschreibt. Fassen Sie diesen Wert nicht an. Ihn zu senken, um einen Angriff abzufedern, schwächt genau die Stelle, die Ihre Benutzerpasswörter schützt.

Die richtige Antwort auf eine Anmeldeflut ist die Verbindungsbremse davor, nicht die Schwächung der Kryptografie dahinter.

Slot-Erschöpfung: wenn der Server voll ist, obwohl niemand spricht

Der vierte Fall braucht keinen einzigen gefälschten Absender. Die Einstellung users begrenzt die Zahl gleichzeitiger Clients, ab Werk auf 100. Solange kein Serverpasswort gesetzt ist, kann sich jeder verbinden, der die Adresse kennt. Hundert Verbindungen von einem Skript, und Ihre eigenen Leute bekommen die Meldung, der Server sei voll. Das kostet den Angreifer fast nichts und ist ohne Serverpasswort nicht zu verhindern.

Woran Sie einen Angriff erkennen

Aussetzer statt Verzögerung

Die zuverlässigste Unterscheidung ist das Ohr. Eine überlastete Anwendung oder ein überfüllter Server klingt nach Verzögerung: Die Stimme kommt spät, aber vollständig an. Ein Netzwerkangriff klingt nach Aussetzern: Silben fehlen, die Stimme wird metallisch, mitten im Satz ist Stille, und nach zwei Sekunden geht es weiter, als wäre nichts gewesen. Der Grund ist der fehlende Wiederholungsmechanismus bei UDP.

Eine zweite Beobachtung grenzt es weiter ein: Wenn die im Client angezeigte Latenz normal bleibt, der Paketverlust aber steigt, liegt es nicht an der Auslastung des Servers. Ein rechnerisch überlasteter Server antwortet spät. Eine volle Leitung antwortet gar nicht.

Die vier Messwerte am Server

Raten hilft nicht, messen schon. Diese vier Werte klären in zwei Minuten, was los ist.

Erstens: was lauscht überhaupt. Als root:

ss -lnup
ss -lntp

Sie sollten den Mumble-Server auf beiden Listen sehen, jeweils auf Port 64738. Je nach Version heißt der Prozess mumble-server oder murmurd. Steht dort zusätzlich 0.0.0.0:6502 statt 127.0.0.1:6502, ist Ihre Ice-Fernsteuerung aus dem ganzen Internet erreichbar, und das ist ein eigenes, größeres Problem als jeder Ping.

Zweitens: die Paketrate der Netzwerkkarte.

ip -s link show eth0

Zweimal im Abstand von zehn Sekunden ausführen und die Differenz der empfangenen Pakete durch zehn teilen. Steigt dieser Wert weit über den Normalwert, obwohl kaum jemand verbunden ist, ist es ein Angriff. Bleibt er unauffällig, liegt die Ursache beim Dienst oder beim Betriebssystem. Die systematische Abgrenzung beschreibt der Beitrag DDoS-Angriff am Server erkennen.

Drittens: eine Stichprobe des ankommenden Verkehrs.

tcpdump -ni eth0 udp port 64738 -c 20

Hier zeigt sich die Ping-Flut sofort, denn tcpdump schreibt die Nutzlastgröße mit. Zeilen mit UDP, length 12 von immer derselben Adresse bedeuten, dass jemand Ihren Server abfragt. Zeilen mit UDP, length 12 von vielen verschiedenen Adressen bedeuten, dass jemand Ihren Server als Reflektor benutzt und diese Adressen die Opfer sind. Für den TCP-Anteil dieselbe Übung:

tcpdump -ni eth0 'tcp port 64738 and tcp[tcpflags] & tcp-syn != 0' -c 20

Viertens: das Serverprotokoll. Auf Debian und Ubuntu liegt es unter:

tail -n 100 /var/log/mumble-server/mumble-server.log

Dort stehen Verbindungsaufbauten, abgewiesene Anmeldungen und die automatisch gesetzten Sperren. Eine lange Kette von Verbindungsversuchen derselben Adresse im Sekundentakt ist eindeutig. Beachten Sie dabei, dass die Konfigurationsdatei eine Einstellung kennt, die IP-Adressen im Protokoll unkenntlich macht. Ist sie eingeschaltet, sehen Sie im Protokoll keine brauchbaren Adressen mehr, und Sie müssen für die Diagnose auf tcpdump ausweichen.

Was Sie am Server selbst tun können

Die folgenden acht Schritte kosten nichts. Sie helfen gegen Ping-Missbrauch, Verbindungsfluten und kleinere UDP-Fluten aus wenigen Quellen. Wo sie aufhören, steht ehrlich im übernächsten Abschnitt.

1. Finden Sie heraus, welche Konfigurationsdatei Sie überhaupt vor sich haben

Das ist der Schritt, an dem die meisten Abende verloren gehen: Man bearbeitet eine Datei, die der laufende Dienst gar nicht liest. Der Ablageort hat sich mit der Umbenennung geändert, und die stabilen Linux-Veröffentlichungen ziehen zeitversetzt nach.

Statt zu raten, lassen Sie sich die Antwort geben. Als root:

ls -l /etc/mumble-server.ini /etc/mumble/mumble-server.ini
systemctl status mumble-server --no-pager

Die zweite Zeile zeigt die vollständige Befehlszeile des laufenden Prozesses, inklusive des Schalters, mit dem die Konfigurationsdatei übergeben wird. Das ist die Datei, die zählt, und keine andere. Wer eine eigene Übersetzung betreibt und keine der Dateien findet, sieht sich die Befehlszeile in der eigenen Unit-Datei an; wie man eine solche aufbaut, zeigt die Anleitung Einen systemd-Service erstellen.

Ein Hinweis zur Schreibweise in der Datei selbst: Kommentare beginnen mit einem Strichpunkt, nicht mit einer Raute. Eine Einstellung, die Sie aktivieren wollen, braucht also einen Strichpunkt weniger am Zeilenanfang. Gesetzte Werte ohne Strichpunkt gelten, auskommentierte Zeilen zeigen nur den Vorgabewert an.

2. allowping abschalten oder die Ping-Rate begrenzen

Der wichtigste Einzelschritt dieses Beitrags, ausführlich weiter oben begründet. In der Konfigurationsdatei:

allowping=false

Danach den Dienst neu starten und gegenprüfen, ob die Antwort wirklich ausbleibt. Das geht von einem zweiten Rechner aus, ohne Zusatzwerkzeug:

nc -u -w 2 ihre-server-adresse 64738 < /dev/null

Einfacher und aussagekräftiger ist der Blick in den Verbindungsdialog des Mumble-Clients: Steht dort nach der Umstellung keine Latenz und keine Benutzerzahl mehr, hat es gewirkt.

3. bandwidth und users auf realistische Werte setzen

Zwei Zeilen, die zusammengehören, weil sie zusammen die Obergrenze Ihres Servers bestimmen.

bandwidth=72000
users=25

bandwidth ist die maximale Bandbreite in Bit pro Sekunde, mit der ein einzelner Client Sprache senden darf. Ältere Fassungen liefern hier 72000 aus, neuere 558000. 558000 Bit pro Sekunde je Benutzer sind für einen Sprachkanal absurd viel, das ist der Kopfraum für Sonderfälle und nicht der Bedarf. Für verständliche Sprache reichen 40000 bis 72000 Bit pro Sekunde bequem aus. Der Wert ist eine Obergrenze, keine Reservierung, aber er ist zugleich der Wert, den der Server in der Ping-Antwort nach außen meldet, und er ist die Rechengrundlage für den schlimmsten Fall: 100 Benutzer mal 558000 Bit ergeben 55,8 Mbit/s allein an eingehender Sprache, und der Server verteilt sie an alle anderen weiter.

users ist die Zahl gleichzeitiger Clients, ab Werk 100. Setzen Sie den Wert auf das, was Ihre Gruppe tatsächlich braucht, plus etwas Luft. Eine Obergrenze von 25 statt 100 macht die Slot-Erschöpfung viermal billiger abzuwehren und begrenzt im selben Zug die Zahl der Sprachströme, die Ihr Server im schlimmsten Fall vervielfältigen muss. Wer nur zehn Leute hat, braucht keine hundert Plätze.

4. Serverpasswort setzen und aus dem öffentlichen Verzeichnis verschwinden

Ein Serverpasswort ist die einzige Maßnahme in dieser Liste, die Slot-Erschöpfung und Anmeldeflut gleichzeitig erledigt, weil beide eine erfolgreiche Anmeldung voraussetzen.

serverpassword=IhrLangesPasswortHier

Dazu kommt ein Nebeneffekt, den man kennen muss, weil er oft für einen Fehler gehalten wird: Ein gesetztes Serverpasswort nimmt den Server automatisch aus dem öffentlichen Serververzeichnis. Die Kommentarzeile in der Konfigurationsdatei sagt es ausdrücklich: Für die Eintragung im öffentlichen Verzeichnis muss das Serverpasswort leer sein. Das ist kein Bug, sondern die Regel des Verzeichnisdienstes.

Wollen Sie die Eintragung unabhängig davon abschalten, lassen Sie die Einstellung für das Registrierungspasswort leer beziehungsweise auskommentiert. Ohne dieses Passwort findet keine Eintragung statt. Achtung, eine Feinheit, die regelmäßig verwechselt wird: Die Einstellung für den Registrierungsnamen erfüllt allein noch einen zweiten Zweck. Ist nur sie gesetzt, benennt sie lediglich den Wurzelkanal um, ohne den Server irgendwo einzutragen. Erst das Registrierungspasswort zusammen mit den übrigen register-Einstellungen löst die Eintragung wirklich aus.

Seien Sie dabei ehrlich zu sich selbst: Der Rückzug aus dem Verzeichnis nimmt einen bequemen Weg, Ihre Adresse zu finden, versteckt sie aber nicht. Ein Scan über den Adressbereich findet einen offenen Port 64738 ohnehin, und zwar in Minuten. Anonymität ist keine Schutzstrategie, ein Passwort schon.

5. Nur die beiden Ports offen lassen, die gebraucht werden

Eine Firewall mit der Grundregel "alles Eingehende verwerfen" ist die Basis. Achten Sie auf die Reihenfolge, sonst sperren Sie sich selbst aus. Den vollständigen Ablauf mit Rettungsweg beschreibt die Anleitung UFW-Firewall einrichten, ohne sich selbst auszusperren. Für einen Mumble-Server sieht das Ergebnis so aus:

ufw allow 22/tcp
ufw allow 64738/tcp
ufw allow 64738/udp
ufw default deny incoming
ufw default allow outgoing
ufw enable

Beide Zeilen für 64738 werden gebraucht. Wer nur TCP freigibt, zwingt sämtliche Clients dauerhaft auf den langsamen Weg über die Steuerverbindung, und niemand versteht, warum der Server so schlecht klingt. Diesen Fehler sieht man häufiger als jede echte Angriffsspur.

6. Ratenbegrenzung mit nftables, getrennt für TCP und UDP

Auf allen vier genannten Systemen arbeitet der Paketfilter unter der Haube mit nftables. Weil TCP und UDP auf demselben Port völlig verschiedene Lastprofile haben, brauchen sie getrennte Regeln. Legen Sie eine eigene Tabelle an, damit eine bestehende UFW-Konfiguration unberührt bleibt:

table inet mumble {
    chain input {
        type filter hook input priority filter; policy accept;

        tcp dport 64738 ct state new meter mumble_conn { ip saddr limit rate over 6/minute burst 12 packets } counter drop

        udp dport 64738 meter mumble_udp { ip saddr limit rate over 300/second burst 600 packets } counter drop
    }
}

Speichern Sie das als /etc/nftables.d/mumble.nft, legen Sie das Verzeichnis bei Bedarf vorher an, und laden Sie es als root:

nft -f /etc/nftables.d/mumble.nft
nft list table inet mumble

Rückgängig gemacht wird es mit nft delete table inet mumble. Nach einem Neustart ist die Tabelle weg, sofern die Datei nicht aus /etc/nftables.conf eingebunden wird.

Zur Größenordnung der gewählten Werte: Ein sprechender Client verpackt in der üblichen Einstellung 20 Millisekunden Ton in ein Paket, das sind 50 Pakete pro Sekunde, dazu die Laufzeitmessung im Sekundentakt. 300 Pakete pro Sekunde je Absenderadresse lassen also mehreren Personen hinter einem gemeinsamen Anschluss reichlich Luft. Auf der TCP-Seite baut ein normaler Client genau eine Verbindung auf und behält sie; sechs Verbindungsaufbauten pro Minute decken auch hartnäckiges Neuverbinden nach einem Netzwechsel ab.

Wollen Sie allowping eingeschaltet lassen, weil Ihr Server im Verzeichnis stehen soll, ergänzen Sie eine engere Regel nur für die Ping-Pakete. Sie sind an ihrer festen Gesamtlänge erkennbar, bei IPv4 sind das 40 Byte:

udp dport 64738 meta length 40 meter mumble_ping { ip saddr limit rate over 2/second burst 5 packets } counter drop

Bei IPv6 lautet der Wert 60 statt 40, weil der IPv6-Kopf 40 statt 20 Byte lang ist. Diese Regel ist eine Heuristik über die Paketlänge und kein Protokollverständnis. Prüfen Sie deshalb nach dem Laden mit nft list table inet mumble, ob der Zähler steigt, während niemand angreift. Steigt er, ist der Wert zu niedrig oder die Längenprüfung trifft echten Verkehr, und Sie nehmen die Regel wieder heraus. allowping=false bleibt der saubere Weg, die Längenregel ist der Kompromiss.

Und jetzt die ehrliche Einordnung: Gegen einen verteilten Angriff auf Ihren Server hilft eine Ratenbegrenzung je Quelladresse kaum, weil der Angreifer die Absenderadresse in jedem Paket neu fälscht. Gegen den Missbrauch Ihres Servers als Reflektor hilft sie sehr gut, weil dort alle Anfragen dieselbe gefälschte Absenderadresse tragen. Beides sind dieselben Regeln, aber nicht derselbe Nutzen.

7. Die eingebaute Sperre gegen Verbindungsfluten richtig einstellen

Mumble bringt eine eigene, grobe Bremse gegen Verbindungsfluten mit. Sie zählt Verbindungsversuche je Adresse in einem Zeitfenster und sperrt die Adresse danach für eine feste Dauer. Die Sperre gilt über alle virtuellen Server einer Instanz hinweg, taucht in keiner Sperrliste auf und lässt sich nur durch einen Neustart des Serverprozesses vorzeitig beenden. Drei Einstellungen steuern sie:

autobanAttempts=10
autobanTimeframe=120
autobanTime=300

Gelesen: Zehn Verbindungsversuche innerhalb von 120 Sekunden führen zu einer Sperre von 300 Sekunden. Das sind die Vorgabewerte, und sie sind bewusst großzügig gewählt, damit ein normal arbeitender Client nicht hineinläuft. Gegen einen Angriff von einer einzelnen Adresse dürfen Sie deutlich enger gehen, etwa fünf Versuche in 60 Sekunden bei 1800 Sekunden Sperre. Abschalten lässt sich die Bremse, indem einer der beiden ersten Werte auf 0 gesetzt wird; tun Sie das nicht.

Dazu gehört eine vierte Einstellung, die regelmäßig für Ärger sorgt. Ab Werk zählen auch erfolgreiche Verbindungen in dieses Fenster hinein. Sitzen mehrere Leute hinter demselben Anschluss und verbinden sich nach einem Serverneustart gleichzeitig, sperrt der Server sie geschlossen aus. Die Konfigurationsdatei sieht dafür eine Einstellung vor, mit der nur noch fehlgeschlagene Versuche gezählt werden:

autobanSuccessfulConnections=false

Diese Kombination ist für die meisten Gruppen die richtige: eng zählen, aber nur das zählen, was auch fehlgeschlagen ist. Wichtig zur Einordnung: Die Bremse greift ausschließlich bei Verbindungen, also auf der TCP-Seite. Gegen eine UDP-Flut oder gegen Ping-Missbrauch richtet sie nichts aus. Dafür sind Schritt 2 und Schritt 6 zuständig.

8. Die Ice-Schnittstelle im Haus behalten

Mumble lässt sich über eine Schnittstelle namens Ice fernsteuern, über die Bots, Statistikskripte und Weboberflächen arbeiten. Ab Werk ist sie an 127.0.0.1 auf Port 6502 gebunden und damit nur lokal erreichbar. Das ist die richtige Einstellung, und Sie sollten sie nicht ändern.

Zwei Dinge sind trotzdem zu tun. Prüfen Sie mit ss -lntp, dass dort wirklich 127.0.0.1:6502 steht und nicht 0.0.0.0:6502. Und setzen Sie die beiden Geheimnisse für lesenden und schreibenden Zugriff, die die Konfigurationsdatei dafür vorsieht; ohne sie kann jeder Prozess auf dem Server die Schnittstelle benutzen. Braucht ein Bot die Schnittstelle von einem anderen Rechner aus, verbinden Sie die beiden Maschinen über ein privates Netz oder ein VPN, statt den Port ins Internet zu stellen. Eine offene Ice-Schnittstelle ist kein DDoS-Problem, sie ist ein Übernahmeproblem, und das ist schlimmer.

Mumble und TeamSpeak im Vergleich

TeamSpeak ist die naheliegende Alternative, und der Vergleich lohnt sich sachlich, weil die beiden Dienste an genau anderen Stellen angreifbar sind. Die TeamSpeak-Werte stammen aus dem Beitrag TeamSpeak-3-Server vor DDoS-Angriffen schützen, der Aufbau eines solchen Servers steht in TeamSpeak-3-Server installieren.

Die zwei Sätze, auf die sich der Vergleich eindampfen lässt: Bei TeamSpeak ist die gefährlichste Angriffsfläche ein separater TCP-Port, den man schließen kann, ohne etwas zu verlieren. Bei Mumble ist sie eine Antwort auf demselben UDP-Port, den der Dienst zwingend braucht, und ihr Abschalten kostet eine sichtbare Komfortfunktion. Das macht Mumble nicht schlechter, es macht die Absicherung nur an einer anderen Stelle nötig.

Wo diese Maßnahmen aufhören

Alle acht Schritte haben eines gemeinsam: Sie greifen erst, wenn das Paket schon da ist. Bei Störern, Ping-Missbrauch und kleinen Fluten reicht das vollständig. Bei einem volumetrischen Angriff reicht es nicht, und zwar aus einem Grund, der mit Ihrer Konfiguration nichts zu tun hat.

Rechnen Sie mit: Eine Anbindung mit 1 Gbit/s überträgt rund 125 Megabyte pro Sekunde und bei kleinsten Paketen etwa 1,49 Millionen Pakete pro Sekunde. Bei 10 Gbit/s sind es entsprechend rund 14,9 Millionen Pakete pro Sekunde. Das ist die harte Obergrenze der Leitung, unabhängig davon, was auf dem Server läuft und wie gut Ihre nftables-Regeln sind.

Entscheidend ist, wo dieser Verkehr aufläuft: nicht auf Ihrer Netzwerkkarte, sondern auf der Leitung davor. Ist dieses Stück Weg voll, gehen die Sprachpakete Ihrer Leute dort verloren, bevor Ihr Server sie je zu sehen bekommt. Eine Firewall-Regel im Betriebssystem kann eine Leitung nicht entlasten, die vor dem Betriebssystem endet. Das ist keine Frage des Könnens, sondern der Reihenfolge.

Dazu kommt die Rechenzeit. Selbst wenn Ihr Kernel Millionen Pakete pro Sekunde verwerfen könnte, kostet jede dieser Entscheidungen CPU. Ein Sprachserver, der mit dem Wegwerfen beschäftigt ist, klingt genauso kaputt wie einer, der gar nicht mehr antwortet. Die allgemeine Fassung dieses Problems beschreibt der Beitrag Server vor DDoS-Angriffen schützen.

Ab dieser Grenze hilft nur noch eines: Der schädliche Verkehr muss verworfen werden, bevor er in Ihre Leitung gelangt. Das kann per Definition nur im Netz davor geschehen, nicht auf Ihrem Server.

Was KernelHost dagegen stellt

Stufe 1: der Dauerschutz, der auf jedem Server inklusive ist

Bei jedem Server von KernelHost läuft die DDoS-Filterung permanent mit, ohne Aufpreis und ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssten. Sie ist zweistufig aufgebaut:

• Ebene 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, lange bevor sie das Rechenzentrum erreichen. Genau das ist die Ebene, die eine Leitung entlastet, die Sie selbst nicht entlasten können.
• Ebene 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und Paket für Paket verworfen, darunter UDP-Fluten und Reflektionsverkehr auf den typischen Sprach- und Gameserver-Ports.

Zwei Punkte sind wichtiger, als sie klingen. Erstens ist der Schutz ab Bereitstellung dauerhaft aktiv und muss nicht erst anspringen, es gibt also keine Anlaufphase, in der ein Angriff durchgeht. Zweitens wird keine angegriffene IP-Adresse aus dem Netz genommen: Kein Nullrouting bedeutet, dass Ihre Leute weiterreden, während gefiltert wird. Wie das für andere Dienste und Protokolle aussieht, beschreibt der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Stufe 2: Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht einmal getroffen, sondern über Wochen. Für diese Fälle gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit. Sie ergänzt den inkludierten Dauerschutz um drei Dinge:

• Eine dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server umgestellt wird. Auf Ihrer Seite ist dafür kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich. Sie stellen 64738/UDP anders ein als 64738/TCP, ohne ein Ticket zu schreiben, und Änderungen greifen in Echtzeit. Bei Mumble ist genau diese Trennung der springende Punkt, weil beide Protokolle auf demselben Port liegen und völlig verschiedene Lastprofile haben.
• Ein Schutzprofil passend zum jeweiligen Dienst, mit fertigen Profilen für über 40 Spiele und Protokolle, Mumble eingeschlossen. Wie diese Profile arbeiten, beschreibt der Beitrag Game-DDoS-Schutz mit Echtzeit-Filterung.

PrePaid heißt hier genau das: keine Mindestlaufzeit, keine Kündigungsfrist, kein Vertrag, keine Einrichtungsgebühr. Sie nehmen den Schutz für die Dauer einer Angriffswelle dazu und lassen ihn danach auslaufen. Für Server, die woanders stehen, gibt es diese Stufe nicht; sie setzt voraus, dass der Server in unserem Netz läuft. Wer dauerhaft beschossen wird und bei einem anderen Anbieter hostet, löst das mit einem Umzug und nicht mit einem Zusatzprodukt.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Die Konfigurationsdatei wird bearbeitet, es ändert sich nichts: Fast immer ist es die falsche Datei. Ältere Systeme lesen /etc/mumble-server.ini, neuere /etc/mumble/mumble-server.ini, und wer den Server aus dem Quelltext betreibt, hat die Datei irgendwo im eigenen Verzeichnis liegen. systemctl status mumble-server --no-pager zeigt die Befehlszeile des laufenden Prozesses und beendet die Diskussion.

Die Einstellung steht in der Datei und gilt trotzdem nicht: Prüfen Sie den Zeilenanfang. Kommentare beginnen in dieser Datei mit einem Strichpunkt. Eine Zeile ;allowping=false ist ein Kommentar und bewirkt nichts.

Nach dem Abschalten von allowping klingt der Server plötzlich schlechter: Prüfen Sie im Client, ob die Verbindung noch als UDP-Verbindung geführt wird. Fällt der Client auf die TCP-Steuerverbindung zurück, steigt die Verzögerung sichtbar. Schalten Sie in diesem Fall allowping versuchsweise wieder ein und begrenzen Sie stattdessen die Ping-Rate im Paketfilter.

Nur 64738/TCP ist freigegeben, alle klagen über Verzögerung: Das ist derselbe Effekt aus anderer Ursache. Ohne offenes 64738/UDP läuft die Sprache über die Steuerverbindung. Öffnen Sie den UDP-Port, die Verzögerung verschwindet innerhalb von Sekunden.

Der Server verschwindet aus dem öffentlichen Verzeichnis, nachdem ein Serverpasswort gesetzt wurde: Das ist kein Fehler, sondern die dokumentierte Regel. Ein Server mit Passwort wird nicht eingetragen. Sie können beides haben, aber nicht gleichzeitig.

Mehrere Leute hinter einem Anschluss fliegen gemeinsam raus: Das ist die eingebaute Verbindungsbremse, die ab Werk auch erfolgreiche Verbindungen mitzählt. Setzen Sie autobanSuccessfulConnections=false. Die Sperre selbst steht in keiner Sperrliste und lässt sich nur aussitzen oder durch einen Neustart des Serverprozesses beenden.

Die Ratenbegrenzung ist zu eng und trifft die eigenen Leute: Typisch ist ein Wohnheim oder eine Familie hinter einem gemeinsamen Anschluss. Für den Filter sieht das aus wie eine Adresse mit auffällig vielen Paketen. Prüfen Sie mit nft list table inet mumble, ob der Zähler steigt, obwohl kein Angriff läuft.

Die Firewall wird scharfgeschaltet und der Zugang ist weg: Bei KVM-Rootservern und Dedicated Servern von KernelHost kommen Sie über die VNC-Konsole im Kundenbereich auf das System. Diese Konsole hängt nicht am Netzwerkstack des Gastsystems, eine Firewall-Regel kann sie also nicht blockieren. Melden Sie sich dort als root an und schalten Sie die Firewall mit ufw disable ab, bevor Sie die Ursache suchen.

Alles ist umgesetzt und der Server ist trotzdem weg: Dann liegt ein volumetrischer Angriff vor, und Sie haben auf dem Server selbst nichts mehr in der Hand. Sammeln Sie die Werte aus ip -s link, die betroffene IP-Adresse, den Port und den Zeitpunkt der ersten Auffälligkeit, und geben Sie das an Ihren Anbieter weiter. Bei KernelHost eröffnen Sie ein Ticket im Kundenbereich; bei laufendem Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfall-Chat unter +43 650 8209883.

Kurz zusammengefasst

• Ein Mumble-Server braucht genau einen Port, 64738, und zwar gleichzeitig über TCP für die Steuerung und über UDP für die Sprache. Fehlt UDP, schiebt der Client die Sprache durch die TCP-Steuerverbindung, und die Verzögerung steigt hörbar.
• Auf 64738/UDP beantwortet der Server eine unverschlüsselte Anfrage von 12 Byte mit 24 Byte Serverdetails, ohne jede Anmeldung. Das ergibt einen Verstärkungsfaktor von 2 auf die Nutzlast und 1,3 auf das IPv4-Paket.
• Mumble ist damit kein Bandbreitenverstärker, sondern ein Paketratenreflektor: Jede Anfrage erzeugt genau ein Antwortpaket beim Opfer, und Paketrate ist die Größe, an der Netzwerktechnik zuerst scheitert.
• allowping=false beendet das. Der Preis ist der leere Verbindungsdialog: keine Latenz, keine Benutzerzahl, keine Bandbreitenangabe vor dem Verbinden.
• Der Dateiname hat sich mit der Umbenennung von Murmur zu Mumble Server geändert, die Namen der Einstellungen nicht. Welche Datei gilt, beantwortet systemctl status mumble-server --no-pager.
• Ein gesetztes Serverpasswort erledigt Slot-Erschöpfung und Anmeldeflut zugleich und nimmt den Server zwangsläufig aus dem öffentlichen Verzeichnis.
• Eine Ratenbegrenzung je Quelladresse wirkt schwach gegen einen Angriff auf Ihren Server und stark gegen dessen Missbrauch als Reflektor, weil dort alle Anfragen dieselbe gefälschte Adresse tragen.
• Ab der Sättigung der Leitung hilft nur noch Filterung im Netz davor: 17 Tbps Scrubbing-Kapazität plus Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main, bei jedem Server inklusive und ohne Nullrouting.