Offene Reflektoren absichern

Dieser Artikel erklärt, was es bedeutet, wenn Dienste auf deinem Server als offene Reflektoren gemeldet werden, und warum das wichtig ist. Danach zeigt er Protokoll für Protokoll, wie du die einzelnen Dienste so konfigurierst, dass sie sich nicht mehr missbrauchen lassen.

So funktionieren Reflection-Angriffe

Da UDP keinen Handshake kennt, kann der Absender eines UDP-Pakets eine beliebige Absenderadresse eintragen. Ein Angreifer sendet kleine Anfragen an viele offene Dienste und gibt die Adresse des Opfers als Absender an. Jeder Dienst antwortet dann dem Opfer, nicht dem Angreifer. Ist die Antwort größer als die Anfrage, vervielfacht sich der Datenverkehr des Angreifers. Das Verhältnis von Antwortgröße zu Anfragegröße wird als Amplification-Faktor bezeichnet.

Für dich hat das konkrete Folgen:

• Dein Server sendet Angriffsdatenverkehr. Dieser stammt von deiner IP-Adresse und beansprucht deine Bandbreite.
• Deine IP-Adresse kann auf Sperrlisten landen. Betreiber angegriffener Netzwerke melden die Quellen, die sie beobachten, und das ist dein Server.
• Deine eigenen Dienste können langsamer werden. Während eines Angriffs konkurriert der reflektierte Datenverkehr auf derselben Uplink-Verbindung mit deinem legitimen Datenverkehr.

Für uns als deinen Netzbetreiber verursacht ein offener Reflektor Probleme, die über deinen Server hinausgehen:

• Er beansprucht Kapazitäten, die alle gemeinsam nutzen. Reflektierter Angriffsdatenverkehr durchläuft unsere Router und unsere Verbindungen zu anderen Netzwerken. Ein großer Angriff beansprucht Kapazitäten, die der Datenverkehr anderer Kunden benötigt.
• Er schadet dem Ruf ganzer Adressbereiche. Sperrlisten und die Filter großer Netzwerke führen oft einen gesamten Bereich auf, nicht nur eine einzelne Adresse. Andere Kunden in diesem Bereich erleben dann, dass ihre E-Mails zurückgewiesen oder ihre Dienste blockiert werden, obwohl ihre Server korrekt konfiguriert sind.
• Er führt zu Beschwerden von angegriffenen Netzwerken. Deren Betreiber senden Missbrauchsbeschwerden an uns als Inhaber der Adresse. Wiederholte Beschwerden belasten unsere Beziehungen zu diesen Netzwerken sowie zu unseren Upstream- und Peering-Partnern.
• Von uns wird erwartet, dass wir Missbrauch aus unserem Netzwerk unterbinden. Deshalb gehen wir proaktiv gegen offene Reflektoren vor, anstatt auf eingehende Beschwerden zu warten.

Lesen des Berichts

Der Bericht enthält eine Tabelle wie diese:

Host        Protocol        Request    Response    Amplification-Factor
10.0.0.1    dns                  25         486                   19.4x
10.0.0.1    snmp                 37         512                   13.8x

Open reflectors:
  10.0.0.1  dns, snmp

Sichere bitte jedes Protokoll in der Tabelle ab, nicht nur das mit dem höchsten Faktor.

Jedes Protokollkapitel erklärt, um welchen Dienst es sich handelt und warum er gemeldet wird. Danach folgt, was du tun musst, solltest und kannst:

• Muss verhindert, dass der Dienst missbraucht werden kann. Ohne diese Maßnahmen bleibt das Problem bestehen, und es folgen weitere Berichte.
• Sollte: sind dringend empfohlene Sicherheitsmaßnahmen, die möglichst auch umgesetzt werden sollten.
• Kann ist eine optionale empfohlene Verbesserung.

Die Links unter Umsetzung führen zur Dokumentation des Anbieters für die gängige Software, da sich Paketnamen, Dateipfade und Dienstnamen je nach Installation unterscheiden. Fragen, die für jedes Protokoll gelten, wie beispielsweise die Einrichtung einer Firewall, werden am Ende in den FAQ beantwortet.

Übersicht

dns (UDP 53)

Ein DNS-Resolver führt im Auftrag seiner Clients Namensauflösungen durch. Das Problem sind offene Resolver: solche, die rekursive Namensauflösungen für jeden im Internet durchführen. Ein autoritativer Server, der nur Anfragen zu deinen eigenen Domains beantwortet, ist nicht Gegenstand dieses Berichts, es sei denn, er löst auch andere Namen auf. Typische Resolver sind BIND, Unbound, dnsmasq, PowerDNS Recursor, der Windows-DNS-Server sowie Werbeblocker wie Pi-hole und AdGuard Home, die auf einem öffentlichen Server installiert sind.

Problematisch weil: Eine kleine Anfrage kann eine sehr umfangreiche Antwort nach sich ziehen, insbesondere wenn DNSSEC-Einträge abgefragt werden. Offene Resolver gehören zu den am häufigsten missbrauchten Reflektoren.

Muss

• Erlaube Rekursion nur für deine eigenen Clients. Auf einem rein autoritativen Server schalte die Rekursion ganz ab.
• Aktiviere auf autoritativen Servern die Antwortratenbegrenzung (RRL).

Sollte

• Greife nur über ein VPN auf deinen Resolver zu oder nutze DNS über TLS oder HTTPS, die über TCP laufen.

Umsetzung

• BIND: Beschränke allow-recursion und allow-query-cache auf deine eigenen Netzwerke. Auf einem rein autoritativen Server schalte die Rekursion mit recursion no; ganz ab. Für RRL gibt es die Option rate-limit.
• Unbound: Lässt standardmäßig nur Anfragen von localhost zu. Prüfe, ob eine access-control-Zeile weitere Netzwerke freigibt und auf welchen Adressen Unbound per interface lauscht.
• dnsmasq: Mit local-service beantwortet dnsmasq nur Anfragen aus direkt angeschlossenen Netzwerken. Die Option greift allerdings nicht mehr, sobald interface, except-interface, listen-address oder auth-server gesetzt ist. Trage dann nur interne Interfaces ein und ergänze bind-interfaces. Details stehen im dnsmasq-Handbuch.
• Windows-DNS-Server: Antwortet der Server nur für seine eigenen Zonen, deaktiviere die Rekursion. Muss er auch für deine Clients auflösen, erlaube die Rekursion nur für diese über Rekursionsbereiche oder schränke ein, wer UDP 53 erreichen darf.
• PowerDNS Recursor: Zuständig ist incoming.allow_from, im älteren Konfigurationsformat allow-from. Standardmäßig sind nur private Adressbereiche zugelassen, ein leerer Wert lässt dagegen alle zu.
• Pi-hole: Wähle als Listening-Modus Allow only local requests. Mit Permit all origins wird Pi-hole zum offenen Resolver.
• AdGuard Home: Trage deine eigenen Clients unter allowed_clients ein.
• systemd-resolved: Der Stub-Resolver lauscht nur auf 127.0.0.53. Fügt DNSStubListenerExtra= eine öffentliche Adresse hinzu, entferne sie.
• NSD und Knot DNS: In NSD heißt die RRL-Option rrl-ratelimit, in Knot DNS übernimmt das Modul mod-rrl diese Aufgabe.

Prüfen

Frage deinen Server von einem Rechner außerhalb deines Netzwerks nach einem Namen, für den er nicht autoritativ ist:

dig @<10.0.0.1> example.com A

Als Antwort muss status: REFUSED kommen oder gar keine. Enthält die Antwort eine ANSWER SECTION mit einer Adresse, löst der Server weiterhin für jeden auf.

snmp (UDP 161)

Mit SNMP (Simple Network Management Protocol) werden Systeme überwacht und verwaltet. Es läuft als snmpd (net-snmp) auf Servern und auf Hardware wie Switches, Routern, Druckern, USV-Netzwerkkarten oder Management-Controllern wie IPMI, iDRAC und iLO.

Problematisch weil: SNMPv1 und v2c authentifizieren nur über einen Community-String im Klartext, und der Standardwert public ist allgemein bekannt. Schon eine einzige Bulk-Anfrage liefert einen großen Teil der Gerätedaten. Die Antwort vervielfacht also nicht nur den Datenverkehr, sondern verrät auch viel über dein System.

Muss

• SNMP darf nicht aus dem Internet erreichbar sein. Nur dein Monitoring-Host darf darauf zugreifen, über eine private Adresse oder eine Firewall-Regel.
• Entferne die Standard-Community public.

Sollte

• Nutze SNMPv3 mit Authentifizierung und Verschlüsselung und deaktiviere v1 und v2c.
• Betreibe Management-Controller nur in einem privaten Netzwerk, nie unter einer öffentlichen Adresse.

Umsetzung

• net-snmp: Ohne passende agentaddress-Einstellung lauscht snmpd auf allen IPv4-Adressen. Setze agentaddress auf localhost oder eine private Adresse. Trage in jeder rocommunity-Zeile die Adresse deines Monitoring-Hosts als Quelle ein und lösche die Zeilen für public. Gib SNMPv3-Benutzern Lesezugriff mit rouser … priv. Alle Optionen beschreibt das snmpd.conf-Handbuch. Vorsicht beim Hilfsprogramm net-snmp-create-v3-user: Ohne weitere Angaben legt es einen Benutzer mit Schreibrechten, MD5 und DES an. Übergib daher -ro und wähle SHA-256 und AES explizit aus.
• Netzwerkgeräte, Drucker und Management-Controller: Deaktiviere SNMP in der Weboberfläche oder beschränke den Zugriff auf deinen Monitoring-Host.

Prüfen

Von einem Host aus, der nicht dein Monitoring-Host ist:

snmpwalk -v2c -c public <10.0.0.1> system

Der Befehl muss mit Timeout: No Response enden.

cldap (UDP 389)

Über CLDAP (Connectionless LDAP) finden Windows-Clients einen Domänencontroller und fragen ihn ab. Jeder Active-Directory-Domänencontroller antwortet darauf, auch Samba-AD-Domänencontroller.

Problematisch weil: Der Domänencontroller beantwortet eine Anfrage ohne jede Authentifizierung mit einer umfangreichen Beschreibung.

Muss

• Ein Domänencontroller darf nicht aus dem Internet erreichbar sein. Sperre UDP 389 und alle anderen Active-Directory-Ports für alle Quellen außer deinen eigenen Netzwerken.
• Betreibe Domänencontroller in einem privaten Netzwerk, etwa einem Hetzner Cloud Network oder einem vSwitch, und binde Außenstandorte und Benutzer per VPN an.

Umsetzung

• Windows: Schränke den Bereich der vordefinierten eingehenden LDAP-Regeln für UDP 389 auf deine eigenen Netzwerke ein. Das wirkt allerdings nur, wenn die Windows-Firewall aktiv ist und keine andere Regel den Port freigibt. Eine Firewall vor dem Server, also die Hetzner Cloud Firewall oder die Robot-Firewall, schützt auch dann, wenn die Regeln auf dem Server selbst fehlerhaft sind. Welche Ports Active Directory nutzt, listet Microsoft unter Firewallkonfiguration für Active-Directory-Domänen und -Vertrauensstellungen auf.
• Samba AD DC: Die Ports listet das Samba-Wiki unter Samba AD DC Port Usage auf.

portmap (UDP 111)

Der Portmapper (rpcbind) teilt Clients mit, auf welchem Port ein RPC-Dienst erreichbar ist. NFS Version 3 und NIS sind darauf angewiesen. Viele Distributionen installieren ihn standardmäßig mit, etwa als Abhängigkeit der NFS-Client-Tools, auch wenn ihn gar nichts nutzt.

Problematisch weil: Eine einzige Anfrage liefert die Liste aller registrierten RPC-Dienste. Sie vervielfacht also nicht nur den Datenverkehr, sondern verrät auch, welche Dienste auf dem Server laufen.

Muss

• Nutzt du weder NFSv3 noch NIS, stoppe und deaktiviere rpcbind. Ein NFSv4-Client braucht ihn nicht.
• Brauchst du NFSv3, gib UDP und TCP 111 sowie die NFS-Ports nur für deine NFS-Clients frei.

Sollte

• Stelle NFS-Server auf reines NFSv4 um, das ohne rpcbind auskommt.

Umsetzung

• rpcbind: Auf Systemen mit systemd deaktiviere zusätzlich die Socket-Unit. Sonst startet die Socket-Aktivierung rpcbind bei der nächsten Anfrage wieder. Siehe das rpcbind-Handbuch.
• Nur NFSv4: Die nötigen Schritte beschreibt Red Hat unter Configuring an NFSv4-only server. Die dort verwendete Einstellung vers3 ist im rpc.nfsd-Handbuch dokumentiert.

memcached (UDP 11211)

memcached ist ein In-Memory-Cache für Webanwendungen. Erreichbar sein muss er nur für die Anwendungsserver.

Problematisch weil: Über UDP löst eine winzige Anfrage eine sehr große Antwort aus. memcached war für einige der größten jemals gemessenen Reflection-Angriffe verantwortlich. Ein offenes memcached erlaubt außerdem jedem, deine gecachten Daten zu lesen und zu verändern.

Muss

• Deaktiviere UDP. Ab Version 1.5.6 ist es standardmäßig abgeschaltet. Aktualisiere ältere Versionen.
• Binde memcached an localhost oder an die private Adresse, über die deine Anwendungsserver zugreifen.
• Gib in Docker nie den UDP-Port frei und TCP nur auf localhost (siehe FAQ).

Sollte

• Mach auch TCP 11211 nicht aus dem Internet erreichbar. memcached hat standardmäßig keine Authentifizierung, der gesamte Cache ist also für jeden les- und schreibbar.

Umsetzung

• memcached: -U 0 deaktiviert UDP, -l legt die Listen-Adresse fest. Wo du diese Optionen setzt, hängt von der Installation ab: in der Konfigurationsdatei des Pakets, in der Service-Definition oder in der Kommandozeile des Containers. Mehr dazu in den Netzwerkoptionen und im Sicherheitshinweis zu UDP-DDoS.

Prüfen

Es darf kein UDP-Listener mehr übrig sein:

sudo ss -ulnp 'sport = :11211'

chargen (UDP 19)

Der Character Generator ist ein Testdienst aus den 1980er-Jahren. Er beantwortet jedes eingehende Paket mit einer Flut von Zeichen. Eine sinnvolle Verwendung gibt es heute nicht mehr.

Problematisch weil: Schon ein einziges Byte löst eine große Antwort aus.

Muss

• Deaktiviere den Dienst.

Sollte

• Deaktiviere auch die übrigen "Simple Services" aus dieser Zeit: echo (7), discard (9), daytime (13) und qotd (17).

Umsetzung

• xinetd: Setze disable = yes in beiden chargen-Einträgen (Datagramm und Stream) und lade xinetd neu. Wird xinetd sonst nicht gebraucht, entferne es ganz. Das Attribut ist im xinetd.conf-Handbuch beschrieben.

• inetd: Kommentiere die chargen-Zeilen in der Konfiguration aus und starte inetd neu.

• Windows: chargen ist Teil der Einfachen TCP/IP-Dienste (englisch Simple TCP/IP Services). Stoppe und deaktiviere den Dienst:

  Stop-Service SimpTcp
  Set-Service SimpTcp -StartupType Disabled

  Alternativ entferne das Feature komplett, unter Windows Server oder unter Windows (Client).

• Drucker und ältere Netzwerkgeräte: Suche in den Einstellungen nach einer Option für Simple TCP/IP Services.

ntp (UDP 123)

NTP (Network Time Protocol) synchronisiert die Systemzeit. Die Zeitsynchronisation selbst ist nicht das Problem, sondern die Verwaltungsschnittstelle des klassischen ntpd und von NTPsec, die Statusabfragen von jedem beantwortet.

Problematisch weil: Statusabfragen liefern ein Vielfaches an Daten zurück. Der monlist-Befehl alter ntpd-Versionen war einer der stärksten jemals missbrauchten Verstärker. Auch die readvar-Abfrage aktueller Versionen liefert noch einen umfangreichen Systemstatus.

Muss

• Lehne Verwaltungsabfragen aus dem Netzwerk ab, über IPv4 wie über IPv6. Die Zeitsynchronisation funktioniert weiterhin, abgewiesen werden nur die Verwaltungsabfragen. Genau das empfiehlt auch RFC 8633, das Best-Practice-Dokument für NTP, für öffentlich erreichbare Server.
• Aktualisiere ntpd-Versionen vor 4.2.7p26, denn diese antworten noch auf monlist (Sicherheitshinweis von ntp.org).

Kann

• Muss der Server nur seine eigene Uhrzeit synchron halten, ersetze ntpd durch chrony oder systemd-timesyncd. Beide stellen standardmäßig weder anderen die Zeit bereit noch beantworten sie Abfragen aus dem Netzwerk.

Umsetzung

• ntpd: Ergänze noquery in den Default-restrict-Zeilen. Siehe die Optionen zur Zugriffskontrolle und zu disable monitor die sonstigen Optionen.
• NTPsec: Nutzt denselben restrict-Befehl, aber mit leicht abweichenden Flags. Siehe die Zugriffskontrolle von NTPsec.
• chrony: Beantwortet nur Anfragen von Clients, die in einer allow-Direktive stehen.

Prüfen

Von einem Rechner außerhalb deines Netzwerks:

ntpq -c rv <10.0.0.1>

Der Befehl muss mit einem Timeout enden.

rdp (UDP 3389)

RDP (Remote Desktop Protocol) ist Microsofts Protokoll für den Remotedesktop. Seit Windows 8 und Windows Server 2012 nutzt RDP neben TCP 3389 auch UDP 3389, um Sitzungen zu beschleunigen.

Problematisch weil: Der UDP-Transport beantwortet eine kurze Verbindungsanfrage mit einer deutlich größeren Antwort, noch bevor sich jemand anmeldet.

Muss

• Mach RDP nicht für das gesamte Internet erreichbar. RDP ist ohnehin ein ständiges Ziel von Brute-Force-Angriffen und Exploits. Lass nur deine eigenen Adressen zu, verbinde dich per VPN oder nutze ein Remotedesktopgateway.
• Muss RDP für alle erreichbar bleiben, schalte den UDP-Transport ab. Sitzungen laufen dann nur noch über TCP. Bei Verbindungen mit Paketverlust ist das etwas langsamer, ansonsten ändert sich nichts.

Umsetzung

• Zugriff beschränken: Microsoft beschreibt das Remotedesktopgateway und empfiehlt für den Zugriff von außen dasselbe Vorgehen.
• UDP-Transport: Zuständig ist die Gruppenrichtlinie Select RDP transport protocols unter Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections (auf deutschen Systemen sind die Bezeichnungen übersetzt). Aktiviere die Richtlinie (Enabled) und wähle Use only TCP. Bei Domänenmitgliedern setze die Richtlinie in der Gruppenrichtlinie der Domäne, weil diese lokale Einstellungen überschreiben kann. Den zugehörigen Registry-Wert nennt Microsoft in der Dokumentation zu Azure Virtual Desktop. Deaktiviere außerdem die eingehende Windows-Firewall-Regel für Remotedesktop über UDP. Wirksam wird die Einstellung nach einem Neustart der Remotedesktopdienste, der offene Sitzungen trennt, oder nach einem Neustart des Systems.

ws-discovery (UDP 3702)

Über WS-Discovery finden sich Geräte im lokalen Netzwerk gegenseitig. Windows nutzt es für die Netzwerkerkennung, Linux- und NAS-Systeme setzen wsdd oder wsdd2 ein, damit ihre Freigaben unter Windows sichtbar sind. Auch ONVIF-IP-Kameras, Videorekorder und Drucker antworten darauf.

Problematisch weil: Auf eine Discovery-Anfrage antwortet das Gerät mit einer Beschreibung seiner selbst. Manche Geräte, vor allem Kameras und Windows-Hosts, antworten sehr ausführlich. Deshalb wurde WS-Discovery schon für einige sehr große Angriffe missbraucht.

Muss

• Lass die Geräteerkennung nie auf einem öffentlichen Interface antworten.

Sollte

• Hänge Kameras und Videorekorder nie direkt an eine öffentliche Adresse. Greife per VPN darauf zu und halte die Firmware aktuell.

Umsetzung

• Windows: Stelle sicher, dass der Netzwerkadapter mit Internetanbindung das Netzwerkprofil Öffentlich (Public) nutzt, und schalte dort die Netzwerkerkennung ab. Auf Servern stoppe und deaktiviere zusätzlich den Dienst FDResPub (Funktionssuche-Ressourcenveröffentlichung), der den Host im Netzwerk bekannt macht:

  Stop-Service FDResPub
  Set-Service FDResPub -StartupType Disabled

• wsdd und wsdd2: Auf einem Server mit Internetanbindung stoppe und deaktiviere den Dienst. Brauchst du die Geräteerkennung in einem privaten Netzwerk, beschränke wsdd mit --interface auf dieses Interface.

• Kameras und Videorekorder: Schalte WS-Discovery bzw. ONVIF-Discovery in den Geräteeinstellungen ab.

Nach der Behebung

Sobald keiner der gemeldeten Dienste mehr antwortet, erhältst du für diese Adresse keine weiteren Berichte. Wird ein Dienst später wieder erreichbar, etwa nach einer Neuinstallation oder weil ein neuer Container ihn freigibt, folgt ein neuer Bericht.

Um deine Änderungen selbst zu prüfen, nutze den Abschnitt Prüfen im jeweiligen Kapitel oder den passenden Client auf einem Rechner außerhalb deines Netzwerks: Er darf keine Antwort mehr bekommen. Hat dein Server eine IPv6-Adresse, wiederhole die Prüfung auch über IPv6.

FAQ

Was gilt für jedes Protokoll?

1. Kläre, ob der Dienst überhaupt aus dem Internet erreichbar sein muss. Die meisten Dienste in dieser Anleitung sind für das lokale Netzwerk oder die Administration gedacht und müssen nie öffentlich erreichbar sein. Nutzt du einen Dienst nicht, stoppe und deaktiviere ihn. Das ist die sauberste Lösung.
2. Finde heraus, welches Programm den Port belegt. Siehe Welches Programm belegt den Port?
3. Binde lokal genutzte Dienste an eine lokale Adresse. Ein Dienst, den nur dein Server selbst oder dein privates Netzwerk braucht, sollte auf 127.0.0.1 oder der privaten Adresse lauschen, nicht auf allen Adressen.
4. Filtere mit einer Firewall. Gib nur die Ports frei, die du tatsächlich öffentlich anbietest, und Verwaltungsports nur für deine eigenen Adressen. Siehe Wie richte ich eine Firewall ein?
5. Denke an IPv6 und Container. Gilt eine Maßnahme nur für IPv4 oder umgehen Container die Firewall, bleibt der Dienst offen. Siehe Warum kann ein Container meine Firewall umgehen?

Welches Programm belegt den Port?

Liste unter Linux alle lauschenden Sockets samt zugehörigem Prozess auf:

sudo ss -lnp
sudo ss -lnp 'sport = :161'

Steht als lokale Adresse 0.0.0.0, * oder [::], lauscht der Dienst auf allen Adressen, also auch auf den öffentlichen. 127.0.0.1 oder [::1] bedeutet: nur lokal erreichbar. Ports, die ein Container freigibt, erscheinen als docker-proxy oder gar nicht. Welcher Container welchen Port freigibt, zeigt docker ps.

Unter Windows in einer PowerShell mit Administratorrechten:

Get-NetUDPEndpoint -LocalPort 161 | ForEach-Object { Get-Process -Id $_.OwningProcess }

Wie richte ich eine Firewall ein?

Am robustesten ist eine Default-Deny-Policy: Alles, was du vergessen hast, bleibt automatisch geschlossen. Gib die benötigten Ports, auch SSH oder RDP, frei, bevor du die Policy auf Deny umstellst. Sonst sperrst du dich selbst aus.

• ufw (Ubuntu, Debian): Firewall-Anleitung von Ubuntu Server und das ufw-Handbuch
• firewalld (RHEL, Rocky, Alma, Fedora, openSUSE): Zonen
• Windows: Eingehende Regel erstellen

Prüfe unter Windows außerdem, ob die Firewall für alle Profile aktiv ist und der Netzwerkadapter mit Internetanbindung das Profil Öffentlich (Public) nutzt:

Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetConnectionProfile

Zusätzlich zur Firewall auf dem Server kannst du den Datenverkehr filtern, bevor er deinen Server überhaupt erreicht:

• Cloud-Server: Die Hetzner Cloud Firewall ist stateful. Antworten auf Verbindungen, die dein Server selbst aufbaut, werden also automatisch durchgelassen.
• Dedicated Server: Die Robot-Firewall ist stateless. Für Antworten auf ausgehende Verbindungen deines Servers brauchst du daher eigene Regeln, die im verlinkten Abschnitt erklärt werden.

Warum kann ein Container meine Firewall umgehen?

Docker legt für freigegebene Ports eigene Paketfilterregeln an, an den Regeln von ufw vorbei. Auch firewalld lässt freigegebene Ports durch, solange die Option StrictForwardPorts nicht aktiviert ist. Ein mit -p 11211:11211/udp gestarteter Container ist deshalb aus dem Internet erreichbar, auch wenn deine Host-Firewall etwas anderes vorsieht. Gib Ports nur auf der Loopback-Adresse frei, oder gar nicht, wenn nur andere Container den Dienst brauchen:

docker run -d -p 127.0.0.1:11211:11211 memcached

Mit Docker Compose:

services:
  cache:
    image: memcached
    ports:
      - "127.0.0.1:11211:11211"

Container mit network_mode: host lauschen direkt auf allen Adressen des Hosts. Das ist bei Medienservern und Discovery-Diensten verbreitet und macht sie genauso erreichbar wie einen Dienst, der direkt auf dem Host installiert ist.

Offizielle Dokumentation:

• Docker: Docker und ufw und Ports freigeben
• firewalld: Docker-Container strikt filtern