[English]Noch ein kurzer Nachtrag von Mitte Mai 2025. Ein Leser informierte mich, dass er wohl Angriffsversuche auf 3CX-Telefonanlagen in seinen Log-Dateien festgestellt hat. Es scheinen weltweite Zugriffsversuche zu sein, wie Diskussionen in Internetforen nahelegen. Ich fasse mal die verfügbaren Informationen zusammen.
Was ist 3CX?
3CX ist ein Softwareentwicklungsunternehmen und Entwickler der gleichnamigen 3CX Telefonanlagen-Software. Es ist ein komplettes Geschäftskommunikationssystems, das Telefonanrufe, Videokonferenzen, Live-Chat, Facebook und die Integration eingehender WhatsApp-Nachrichten umfasst. Das Unternehmen wurde 2005 gegründet, residiert auf Zypern und hat laut Wikipedia ca. 200 Beschäftigte (Stand 2018).
Hinweis auf Angriffe
Blog-Leser Aaron G. hat mich bereits zum 13. Mai 2025 per Mail kontaktiert (danke dafür, ist hier etwas liegen geblieben), weil ihm Merkwürdigkeiten in den logs von 3CX- Telefonanlagen aufgefallen waren. Er schrieb, dass "in letzter Zeit (mal wieder am letzten Wochenende)" 3CX-Telefonanlagen angegriffen wurden. In seinem Umfeld konnte der Leser das Problem bei verschiedenen Kundenanlagen nachvollziehen, wo folgends im log zu finden war:
Unidentified Incoming Call. Review INVITE and adjust source identification: INVITE sip:0018163016305@xx.xx.xx.xx SIP/2.0 Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK626440;received=172.86.68.235 Max-Forwards: 70 Contact: <sip:1001@xx.xx.xx.xx:5060> To: <sip:0018163016305@xx.xx.xx.xx> From: <sip:1001@xx.xx.xx.xx>;tag=945943 Call-ID: 3774@xx.xx.xx.xx CSeq: 1 INVITE Content-Type: application/sdp Content-Length: 390 v=0 o=- 0 0 IN IP4 127.0.0.1 s=VoIP Call c=IN IP4 127.0.0.1 t=0 0 m=audio 4000 RTP/AVP 0 8 18 3 4 101 9 97 98 109 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 a=rtpmap:4 G723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:9 G722/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:98 speex/8000 a=rtpmap:109 opus/48000/2 a=sendrecv
In obigem Auszug wurde die IP-Adresse des Kunden durch xx.xx.xx.xx ersetzt. Die IP, von der der Angriff kam, ist die 172.86.68.235. Der Leser hat mir folgendes Beispiel aus dem Call-Log mitgeschickt:
Der Leser schrieb, dass der Angriff bei einem seiner Kunden leider erfolgreich war und unzählige Anrufe gestartet wurden. Warum die 3CX-Telefonanlage den Anruf auf einer Leitung durchstellte, ist bisher unklar. Glück für den Kunden, dass der Provider am Ende die Verbindungen dann geblockt hat, so dass keine Kosten aufliefen.
Auch Meldungen in Foren
Der Blog-Leser hat mir dann noch einen Link auf den 3CD-Foren-Thread Angriffe auf 3CX-Anlagen mitgeschickt, wo ein massiver Versuch per SIP-intrusion Anrufe zu tätigen über mehrere Anfragen über sämtliche Telefonanlagen hinweg unter #5 berichtet wurde.
Weiterhin gibt es auf reddit.com den Thread Some customer extensions hacked. Zero day?, wo ein Betroffener bereits vor fünf Monaten (also Anfang 2025) von einer ähnlichen Beobachtung berichtete. Der Betroffene berichtet, dass er einige Systeme mit gehackter Erweiterung habe, von denen Anrufe nach Frankreich und Italien getätigt wurden. Seltsam sei, dass es in mehreren Systemen der Versionen v18 und v20 passierte.
Ähnliche Artikel
Die 3CX MySQL-Sicherheitslücke und der Umgang mit Kritik durch den Anbieter
3CX-Warnung: SQL-Datenbankintegrationen deaktivieren (15. Dez. 2023)
Kickt 3CX Partner mit mangelndem Umsatz?
3CX: Update-Zwang für NFR-Lizenz auf Version 20 seit 15.11.2024
MVP: 2013 – 2016
Das passiert eigentlich schon immer, seit dem der SIP-Port an VoIP-Anlagen aus dem Internet erreichbar ist. Selbst die FritzBOX protokolliert solche "Versuche" wenn man den Port zum Internet hin offen hat. Da wollen halt findige Typen günstig "Sonderrufnummern" anrufen oder andere "Schweinerrein" mit dem Telefonsystem anstellen. Das ist nun wirklich kein Exklusiver 3CX-Angriff. Wenn man jeden Port-Zugriff auf "irgendwas" als Angriff auf das jeweilige Produkt werten würde….
Das ist unerwünscht, aber nicht automatisch ein Problem. Die Anlage führt selbst ein Fail2Ban und kann optional auch eine Cloud-Based IP-Liste mit laden. Davor ne Firewall die sich von AbuseIPDB die IP-Liste der größten "Angreifer" holt und dann kann man den Defcon ruhig wieder auf 3 ruhig wieder auf 4 schalten….
Die Sicherheitsmaßnahmen sind eigentlich unntötig, wenn man eine anständig konfigurierte Firewall hat, die nur Verbindungen von der Telefonanlage zum SIP-Registrar (bzw. umgekehrt) zulassen.
Warum ist das SIP Port offen?
Vermutlich weil 3cx bis heute auf ihrer Homepage behauptet, dass das nötig sei: https://www.3cx.de/docs/adminhandbuch/firewall-router-konfiguration/
Ist ja auch korrekt; man muss es halt anständig umsetzen! Das ist allerdings nicht die Aufgabe vom Anbieter einer Software und trotzdem werden, wenn man deinem Link folgt, im unteren Bereich Anweisungen für gängige Firewalls angeboten!
Outbound-NAT Regel (Einfache Basis-/Standardkonfiguration)
Schnittstelle: 'WAN'
Protokoll(e): TCP/UDP (unverschlüsselt) | TCP (SSL/TSL)
Quelladresse(n): 'TELEFONANLAGE'
Quellport(s): 5060 (unverschlüsselt) | 5061 (SSL/TLS)
Statischer Port: X (!)
Dadurch wird während der Registrierung beim SIP Provider ein statusbehafteter (stateful) Weg geschaffen, der eingehende Verbindungen nur vom eigenen Anbieter zulässt, wobei der der statische Port wichtig ist, weil der Änderungen davon nicht mitbekommt.
Je nach Eigenart/Einstellung der Firewall muss die Telefonanlage zusätzlich noch regelmäßig Anfragen schicken, um den Port erreichbar zu halten ("Keepalive").
Das steht dort nirgends, dass das Port offenbleiben muss/soll. Nur dass man es so einstellen soll, dass man mit dem Provider sprechen kann.
Fehlkonfiguration. Normalerweise nimmt man SIP-Pakete nur vom hinterlegten Telefonieprovider und dessen im SRV-Record angegebenen Servern an.
Die Telekom erzwingt das bei ihren Endkundenprodukten und -routern sogar.
LANCOM. Fritz! und die Digitalisierungsboxen machen es nur so.
Einen offenen SIP-Port will man nur im internen Netz, zu den Endgeräten hin.
Vermutlich ist die 3CX einfach falsch konfiguriert.
Naja, wenn der Hersteller auf seiner Seite eine solche Konfig angibt, wird das schon seine Gründe haben.
Zumal SIP im internen Netz… gestaltet sich schwierig, wenn es Endgeräte gibt, die auch außerhalb des internen Netzes stehen ( so im Zeitalter von Homeoffice etc.). Der Aufwand eines VPN's nur für Telefon, da machen nur die wenigsten mit…
WireGuard-VPN hatte ich mir schon eingerichtet, bevor ich jetzt in Verlegenheit kam, auch unterwegs unter der Festnetznummer (ohne Rufumleitung) oder in Zukunft für die Türsprechanlage, das sind dann "interne" Anrufe, erreichbar sein zu wollen.
Schnell eingerichtet und funktioniert.
Die Notwendigkeit des offenen Ports 5060 im Fall der Fritzbox bei eingerichteten öffentlichen SIP-Nummern ist aber weiterhin unklar.
Habe zwei Fritzboxen, die eine hat solche Rufnummern, von denen ich eine mal in einer per WireGuard-Tunnel angebundenen Box eingetragen habe, die keine öffentlich IP hat. Auch diese Telefonnummer ist dann anrufbar, entweder kaspern die beiden Boxen das untereinander ab, damit das funktioniert oder es funktioniert dennoch.
Bei Kuketz im Forum wird das mehr oder weniger heiß in einem Thread diskutiert.
Man könnte ansich auch mal im IP-Phone-Forum fragen, dort gibt es auch intensiv 3CX-Werbung, aber ich finde gerade meine Zugangsdaten nicht und möchte mich auch nach Jahren nicht erneut neu anmelden.
Die FRITZ!Box ohne öffentliche IP holt sich per STUN (Session Traversal Utilities for NAT) die WAN-Adresse und teilt diese dem SIP-Registrar mit, der dann weiß, wo die Telefonanlage erreichbar ist. Durch den ausgehenden Verbindungsaufbau zu $SipRegistrar werden entsprechend eingehende Verbindungen von $SipRegistrar zugelassen (vgl. Stateful Packet Firewall).
Ähnlich ist es mit der WireGuard- Verbindung, nur die NICHT per öffentlicher IP erreichbare Box kann die Verbindung hier aufbauen, über die dann die gesamte Kommunikation läuft.
Wozu benötigt es dann den offenen Port auf WAN-Seite aus Sicht von AVM für die Fritzbox?
Sonst müßte die erste Box "wissen", welche Nummer die zweite Box registriert hat, um ihr das weiterzureichen, also die Registrierung mitschneiden, falls jemand von außen anklopft.
Ich könnte das Spielchen auch weitertreiben, entweder parallel zur oder hinter die zweite Box noch eine hängen.
Zweiteres hatte ich schon, aber noch nicht in zweiter und dritter Box jeweils eine Nummer und das Anrufen getestet.
Irgendwie machst du komische Sachen :)
Wenn du zwei FRITZ!Boxen hintereinander hängst könnte die WAN-Box den Port 5060 für die eigenen Telefoniegeräte verwenden und Anfragen an sich selbst annehmen, während sie den Quellport der internen Box auf einen Anderen (z.B. 5061) umschreibt und entsprechende Anrufe dann dorthin weiterleitet.
Ich habe auch irgendwas im Hinterkopf, dass bei entsprechender Erkennung von VoIP Verbindungen automatische Regeln (Outbound-NAT) erstellt werden. Wissen müsste die "erste Box" dann nichts weiter und mit VPN hat das auch eher nichts zu tun.
Wenn nur die interne Box eine Verbindung aufbauen kann oder soll, braucht es trotzdem einen Port auf der WAN-Seite für eingehende Signale, die dann entsprechend weitergeleitet werden.
Theoretisch könnte ein Telefon außerhalb vom Firmennetz per STUN die WAN-IP vom externen Anschluss auslesen und die Infos inklusiver eindeutiger Identifikation nach Authentifizierung bei irgendeinem Webserver abgeben. Dann könnten diese Daten an die Telefonanlage weitergegeben oder von dieser regelmäßig abgeholt werden, die danach entsprechend den/die Port/s für die IP an der Firewall durch einen Verbindungsaufbau zum externen Router öffnet. Ob es sowas gibt weiß ich aber nicht!
Ich bin mir an der Stelle nicht sicher, ob wirklich der Hersteller einen Fehler macht oder der Kunde, weil er nicht lesen kann.
Das erste Bild von Deinem Link zeigt unter "Erforderliche Ports für Ihren SIP-Trunk/VoIP-Anbieter" links zwar eine kleine Wolke, die man üblicherweise mit "Das Internet" assoziiert, im vorliegenden Fall ist sie aber ausdrücklich mit "VoIP Provider" beschriftet.
Auch der beschreibende Text sagt klar "Öffnen Sie die folgenden Ports in Ihrer Firewall, damit 3CX *mit* *Ihrem* *VoIP-Anbieter/SIP-Trunk* und per WebRTC kommunizieren kann:"
Letztendlich ist das genau das, was ich in meinem Kommentar oben mit "hinterlegter Telefonie-Provider" meinte.
Wenn der Einsender des Logs im Artikel, Aaron G. nicht gerade Telefoniedienste bei einem Anbieter "Ponynet" in Wyoming, USA gebucht hat, frage ich mich weiterhin, warum die Firewall SIP-Pakete von der IP 172.86.68.235 überhaupt annimmt.
Sicherlich kann man wie in der Diskussion vorgeschlagen IPs von "bösen Jungs" mit entsprechenden Sperrlisten oder Fail2Ban blockieren, im vorliegenden Fall ist es aber doch trivial, es andersherum zu machen: Dem Telefonieanbieter und seinem Netz vertraut man, alle anderen haben keine Veranlassung, irgendwas an den SIP-Port zu senden.
https://www.abuseipdb.com/check/172.86.68.235
berühmtberüchtigte IP-Adresse
Ich habe bei Kunden sowohl on-prem als auch die hosted 3CX, was soll ich sagen, sogar bei der gehosteten Anlage liegen ähliche Angriffe vor. Heißt also für dich, dass 3CX selbst alles falsch konfiguriert? Glaube da arbeiten genug qualifizierte Leute, warum es so und nicht anders gehandhabt wird. Oder vielleicht den 3CX Jungs und Mädels mal schreiben, dass sie alles falsch machen?
Ganz ehrlich. Software die einen Port ins Internet haben will sollte man nicht in seinem Netz haben wollen. Der einzige akzeptable Port ist einer für ein VPN. Software die damit nicht klar kommt ist Bruch und gehört entsorgt.
Gruß
Damit die Telefonanlage überhaupt für eingehende Anrufe erreichbar ist bzw. Gespräche "eingeleitet" werden können (SIP = engl. Session Initiation Protocol).
Den SIP Port zu öffnen ist nur dann nötig, wenn sich z.B. Telefone von außen ohne VPN einwählen sollen. Das können SIP Softphones sein oder irgendwelche Hardware Telephone.
Um die 3CX nur im eigenen LAN zu betreiben ist es absolut unnötig (selbst mehrmals so eingerichtet), trotzdem schreibt der Hersteller das auf seiner Seite.
Daraus kann man jetzt evtl. seine Schlüsse über die Firma und das Produkt ziehen, wenn das grundlegende Protokoll des Produktes offenbar nicht verstanden wurde.
@TAFKAegal
Aastra Opencom / Mitel 100 Serie hat das auch ohne eingehende Portforwardings hinbekommen.
Wer redet von Port Forwarding?
3CX in seiner Anleitung und was sollte ein "Port aus dem Internet erreichbar" sonst sein, wenn kein Portforwarding?
Durchreichen von Anfragen mit quelleninitiiertem-, also Source- bzw. Outbound-NAT und statischem Port. Das lässt eingehende Verbindungen nur zu, nachdem vorher eine von innen zum 'Anfrager' außen aufgebaut und somit erlaubt wurde. Gewöhnliches "Port-Forwarding" ist Destination-NAT und und kommt einer dauerhafte Öffnung gleich.
Solche Ereignisse haben wir seit kurzem auch in unserer 3CX. Vorher hatten wir die nicht. Bei uns kommen diese Angriffe von mehreren IPs!
Angriffe auf VOIP-Anlagen fanden schon immer statt. So sehen die Logs unser 3CX Anlagen seit Jahren aus…
die Angriffe kann ich auch bestätigen.
Wir haben als Maßnahme mit allen Benutzern zusammen die Passwörter geändert und eine höhere Mindestkomplexität festgelegt sowie 2FA. Damit die Benutzer nicht auf dumme gedanken kommen und Varianten von Start123#! nutzen, haben wir die Benutzer bei der Änderung begleitet.
Ist viel Aufwand, aber leider hat man sonst immer einen Schlaumeier dabei, der es irgendwie schafft, ein unsicheres Kennwort festzulegen oder ein Kennwort für alles nutzt.
Das hilft zwar nicht gegen Zero Day lücken, aber bisher gibt es darüber auch keine gesicherten Berichte.
Wir haben auch 3CX self hostet im Einsatz.
Die "Angriffe" kommen alle paar Monate in Phasen vor, als nix neues.
Weil es für DICH nichts Neues ist, deshalb ist es nicht wert darüber zu sprechen? Diese Denke sieht man öfter – immer wieder eine schräge Logik.
3CX Admin seit Version 10 hier. Es sind mehrer Faktoren.
1. Wie einige Vorposter gesagt haben: SIP UDP 5060/5061 gehört nur für die jeweiligen Provider geöffnet, nicht fürs ganze Internet (3CX sieht dies anders). Für Softphones existiert UDP plus TCP 5090 fürs 3CX "VPN" über den 3CX Client.
2. STUN für Hardphones wird seit Version 20 nicht mehr unterstützt (musste ich leider auch feststellen). Die Lösung für entfernte Hardphones sind sogenannte Router-Phones welche einen internen SBC aufbauen können, und dieser funktioniert ebenfalls über UDP plus TCP 5090. Diese sind jedoch eher neue Modelle, hauptsächlich Fanvil XxU-V2, Fanvil V6x, Yealink T5x. Siehe auch https://www.3cx.de/blog/sbc-router-telefon/.
3. Seit V18 können keine "kurzen" Passworte mehr vergeben werden, der Username ist auch nicht mehr die (interne) Nebenstellennummer. Wer aber die Anlage über X Jahre nur aktualisiert hat, der hat eventuell noch User mit exterem kurzen Passworten. Dort die Credentials neu generieren lassen.
4. Das grösste aha-Erlebnis hatte ich jedoch mit dem Aufruf von der Homepage https://crt.sh/?q=3cx.de, filtert mal die expired raus (Haken oben). 3CX fordert explizit FQDN (ist auch logisch), diese weisen immer ein Zertifikat auf, und den eigenen FQDN gibt es erst ab der "Enterprise" Variante, dehalb wählen viele/alle Deutschen Kunden die 3cx.de Domäne die Schweizer 3cx.ch etc. Fix-fertige Liste von gültigen FQDNs fürs "experimentieren", a.k.a. Angriffe planen.
Nachtrag: Es gibt noch eine Möglichkeit, sich Subdomains anzeigen zu lassen. Weil diese Liste noch akkurater ist als "crt.sh" erläutere ich nicht weiter. Und "nein", das hat bisher noch nichts mit hacking im übliuchen Sinne zu tun. Einfach eine rekursive Suche im DNS, mehr nicht.
Es existieren 9762 Domains welche mit .3cx.ch enden, 10 random getestet, alle online bzw. erreichbar via HTTPS und den üblichen TCP Ports…
Im Gegensatz zur oben geäußerten Vermutung scheinen die Leute von 3CX nicht wirklich zu wissen, was sie tun.
Die Website "www.3cx.de" ist mit einem Zertifikat abgesichert, welches als Alternativname auch "*.3cx.de" einhaltet. Damit könnten auf einen Schlag alle Subdomains abgesichert werden und die tausenden unter "crt.sh" gelisteten Einzelzertifikate ersetzen.
Übrigens unterstützt auch Let's Encrypt Wildcard-Zertifikate, die man mit der DNS-01 Challange automatisiert anfordern kann.
Naja nenn mir einen SIP Telefonie Anbieter der seinen Job richtig macht… ich kenne keinen!
Gut es gibt da Anbieter die nur "kleine bugs" und keine großen Hunde vergraben haben… aber wirklich anstandslos ohne Fehler? Das ist ein Minenfeld.
>Nachtrag: Es gibt noch eine Möglichkeit, sich Subdomains anzeigen zu >lassen. Weil diese Liste noch akkurater ist als "crt.sh" erläutere ich nicht >weiter.
crh.sh kann die Subdomains nur anzeigen, weil da Zertifikate involviert sind vermute ich.
Kann die o.g. andere Möglichkeit auch Subdomains anzeigen kein Zertificat haben?