ultrasrv.de hat meinen Docker-Traffic gekapert

  • In den letzten Tagen ist mir bei der Bereitstellung von Docker-Diensten auf meinem Server etwas ziemlich Merkwürdiges aufgefallen. Ursprünglich wollte ich lediglich über den Kurznamen crowdsec auf meinen Container-Dienst zugreifen. Nach einigem Hin und Her stellte ich jedoch fest, dass der Traffic den Container gar nicht erst erreichte, sondern stattdessen an die IP-Adresse 46.38.243.234 weitergeleitet wurde.

    Ich habe sofort die resolv.conf des Servers überprüft und die Ursache gefunden: Die von Netcup via DHCP konfigurierte Search-Domain search ultrasrv.de. Da mein interner Dienst zufällig ebenfalls crowdsec heißt, versuchte der Linux-Resolver bei der Verarbeitung dieses Kurznamens vorrangig die Suchdomäne anzuhängen. Das Ergebnis: Meine lokale Anfrage wurde automatisch zu crowdsec.ultrasrv.de vervollständigt.

    Wie es der Zufall will, lautet der Hostname des Servers unter der IP 46.38.243.234 tatsächlich ebenfalls crowdsec, weshalb der Datenverkehr direkt auf diesem mir unbekannten Server landete. Anfangs vermutete ich einen offiziellen CrowdSec-Dienst von Netcup, aber die IP ist nicht pingbar und auf Port 8080 wird kein Dienst angeboten.

    Ich bin mir unsicher, ob hier lediglich jemand anderes seinem Server denselben Namen gegeben hat oder ob es sich um einen bewussten Streich oder gar einen "Honeypot" bzw. "Honeybadger" handelt. Fest steht jedoch: Es hat meine interne Docker-Namensauflösung effektiv abgefangen. Ich denke, es wäre für alle sinnvoll, die eigenen CrowdSec-Setups (oder andere Dienste mit kurzen Namen) auf ähnliche Probleme zu überprüfen.

  • Es gibt einen Wildcard DNS Eintrag *.ultrasrv.de, der auf diese IP zeigt. D.h. jeder beliebige Hostname unter dieser Domain, der keinen expliziten A Record hat, wird auf diese IP aufgelöst. Siehe z.B.

    Code
    ❭ dig +short shannon.ultrasrv.de
    46.38.243.234

    2 Mal editiert, zuletzt von Paul (12. März 2026 um 17:26)

  • Würde generell empfehlen von DHCP auf eine statische Konfiguration zu wechseln. Da der Server sowieso eine statische IP hat, müssen mit aktivem DHCP beim Serverstart nur unnötig Pakete durchs Netzwerk geschickt werden, die den Serverstart etwas verlangsamen, nur um Informationen zu bekommen die man eh schon hat. Zum anderen ist die Standard-Suchdomäne einfach unnötig und irritierend.

    Für den ein oder anderen kann es auch sinnvoll sein noch andere DNS-Server mit einzutragen, zumindest habe ich das bei meinen Servern beobachtet, das die netcup-DNS-Server hin und wieder "Schluckauf" zu haben scheinen und nicht auf die Anfrage antworten. Ist bei meinem Mailserver dann schon bisschen nervig, wenn der DNS-Einträge nicht auflösen kann und der Spamfilter deshalb Mails nicht ordentlich bewerten kann.

  • Würde generell empfehlen von DHCP auf eine statische Konfiguration zu wechseln. Da der Server sowieso eine statische IP hat, müssen mit aktivem DHCP beim Serverstart nur unnötig Pakete durchs Netzwerk geschickt werden, die den Serverstart etwas verlangsamen, nur um Informationen zu bekommen die man eh schon hat. Zum anderen ist die Standard-Suchdomäne einfach unnötig und irritierend.

    Für den ein oder anderen kann es auch sinnvoll sein noch andere DNS-Server mit einzutragen, zumindest habe ich das bei meinen Servern beobachtet, das die netcup-DNS-Server hin und wieder "Schluckauf" zu haben scheinen und nicht auf die Anfrage antworten. Ist bei meinem Mailserver dann schon bisschen nervig, wenn der DNS-Einträge nicht auflösen kann und der Spamfilter deshalb Mails nicht ordentlich bewerten kann.

    Wusste gar nicht, dass netcup DHCP nutzt, ich kenne das nur von anderen Anbietern. Bei meinen Servern mit dem Debian 13 Minimal Image von netcup war das jedenfalls nicht so konfiguriert. Es mag allerdings Default sein, wenn man das OS manuell selbst installiert.

    Bei einem Mailserver würde ich sagen, dass es eigentlich fast schon Pflcht ist, nicht die netcup-Resolver oder auch andere öffentlich zugängliche Resolver (Google, Cloudflare, ....) zu nutzen. Andernfalls wird man jedenfalls DNS-Blocklisten nicht oder nur sehr eingeschränkt nutzen können. Ausnahmsweise hier mal nicht nur wegen Datenschutz.