Hallo zusammen,

bei einem externen Portscan meines Anschlusses ist mir aufgefallen, dass TCP-Port 8008 als offen gemeldet wird, obwohl ich außer WireGuard (UDP 51820) keine Portfreigaben eingerichtet habe. Ich habe das systematisch nachvollzogen:

Setup:

• Router: Speedport Smart 4
• Portfreigaben: nur UDP 51820 (WireGuard)
• Öffentliche IPv4: 91.49.x.x (dip0.t-ipconnect.de)

Befunde:

• nmap -sV -Pn --version-intensity 9 -p8008 <IP>

  → Port als "open" gemeldet, Service konnte aber trotz ~8 Minuten Intensivscan nicht identifiziert werden (http?, nur geraten)

• curl -v http://<IP>:8008/

  → TCP-Verbindung wird angenommen, aber "Empty reply from server"

• curl -v -k https://<IP>:8008/

  → TLS-ClientHello scheitert mit SSL_ERROR_SYSCALL

• nc -v -w 5/8 <IP> 8008

  → Verbindung wird angenommen, auch ohne jede Eingabe kommt über mehrere Sekunden keine Antwort
• Ein Scan von innerhalb meines Netzes (LAN-Geräte sowie ein Docker-Container) auf denselben Port 8008 meldet "closed" – es läuft also nachweislich kein Dienst auf einem meiner Geräte, der über eine Portfreigabe erreichbar wäre. 
• tcpdump -i any -nn 'tcp port 8008' -v zeigt 0 Pakete bei einem curl Zugriffsversuch, d.h. der TCP-Traffic zu Port 8008 erreicht mein LAN nachweislich nicht 

Fazit meinerseits: Der TCP-Handshake auf Port 8008 wird offenbar von einer Instanz vor oder auf dem Speedport selbst beantwortet, nicht von einem Gerät in meinem LAN. Auf keine gesendete Payload (HTTP, TLS, leere Bytes) folgt jemals eine Antwort.

Meine Frage: Ist dieses Verhalten bekannt (z. B. eine interne Diagnose-/Fernwartungsschnittstelle oder ein bewusstes Tarpit-artiges Verhalten gegen Portscanner)? Und falls ja: Ist das dokumentiert, oder kann das jemand aus dem Digital Home Service intern nachverfolgen? Würde mich über euren (@Telekom) fachlichen Input freuen, da ich gerne verstehen würde, ob ich hier ein Risiko habe.

Vielen Dank vorab!