10
3CX - das schwarze Loch in der Firewall?
Hallo, liebe Kollegen,
ich habe endlich mal eine 3CX in die Finger bekommen. VoIP mache ich recht gern und üblicherweise verwende ich asterisk nativ, etwas eingelesen hatte ich mich aber schon vor einem guten Jahr in die 3CX. Diese habe ich nun bei einem Neukunden geerbt. Also Zeit, wieder was zu lernen. Von Euch
Die 3CX ist ja fürs KMU eher unspektakulär, aber recht easy zu bedienen. Die vorgefundene ist von einem 3CX-Partner eingerichtet worden, der auf seine Zertifizierung verweist (3CX CE, Sophos CA, CE). Meine Augen öffneten sich allerdings nicht unerheblich, als ich die Portfreigaben auf der Sophos ansah:
Die Sophos ist zur Anlage hin offen, wie ein Scheunentor: Ports 3479, 5000, 5001, 5060, 5061, 5090 9000-10999 sind freigegeben. Nun gibt es ja von 3CX eine hübsche Anleitung für die Firewalleinstellungen, die sicherlich vielen als Basis dient(e). Auch dem 3CX CE in meinem Fall, denke ich. Nach mehr als 15 Jahren mit Asterisk, das ohne eine einzige Freigabe für extern läuft, kommt man da schon ins Grübeln. Klar, 3CX hat einige Funktionen, die Zugriff von außen erfordern. Wenn man sie denn nutzt. Aber pauschal 5060, und 2000 Ports RTP?
Zumindest eine Betrachtung wert, denke ich. Der Reihe nach:
3CX: Für Ihren SIP-Trunk/VoIP-Provider
9000-10999 eigehend für RTP vom VoIP-Anbieter? - imo ebenso nicht erforderlich. Das interne Endgerät aka Telefon meldet den/die gewünschten RTP-Ports an die Anlage und diese übermittelt die Ports an die Gegenstelle. Wenn jetzt symmetrisches RTP verwendet wird und die Firewall damit umgehen kann, öffnet also auch hier das Endgerät faktisch die benötigten Ports. Eingehende Freigaben nicht erforderlich.
Was mich irritiert: Warum kommuniziert 3CX das so? Auf mich wirkt das so als opferte man hier den Schutz einer zentralen Hardware-Firewall sehenden Auges, um den Betrieb des eigenen Produktes möglichst "reibungslos" zu ermöglichen. Oder gibt es aus Eurer Sicht andere Gründe, diese Ports für die Kommunikation zum VoIP-Anbieter zu öffnen. Dann her damit
Klar ist, wenn ich Geräte von außen ranhänge, brauche ich Ports. Dann natürlich auch RTP, wenn ein externes Telefon mit der Anlage arbeiten möchte. Solche Setups sind nicht unüblich, aber im KMU-Umfeld eher selten. Und das würde ja eher unter dem Punkt "Anbindung externer Geräte" stehen, nicht unter Kommunikation "mit Ihrem VoIP-Anbieter". Und man würde doch auch die Source beschränken... Oder ein VPN nutzen.
3CX: Für externe 3CX Applikationen und den 3CX SBC
3CX: Für 3CX Videokonferenzen
Zusammen fassend kann man sicher darüber diskutieren, ob die Freigabe einer Portrange (auf einen einzelnen Server) per se ein Sicherheitsrisiko darstellt, zumal 3CX imo ein Konfigurationstool für die jeweilige Gerätefirewall mitliefert. Aber 5060 am WAN ohne Not(wendigkeit) offen - im Installationsbeispiel hier sogar ohne Source-Adress-Beschränkung - das macht mich sprachlos. Hier hängt die Sicherheit (u.U.) des gesamten Netzes am Ende am SIP-Passwort. Wenn ich richtig liege, wäre mein Vertrauen in einen Anbieter, der seinen Kunden derartige Empfehlungen gibt doch stark beeinträchtigt. Ich würde dann denken: Wer weiß, wie die in der Programmierung mit dem Thema Sicherheit verfahren?
Aber vielleicht seht Ihr das ja anders, ich freue mich ggf. auf etwaige Erläuterungen. Wie seht Ihr das?
Die Anlage ist ja sehr verbreitet und ich weiß, dass einige von Euch die 3CX (gern) verbauen. Und ich finde die Bedienung eingängig und die Vielzahl an Erläuterungen und Anleitungen des Anbieters im Web auf den ersten Blick vorbildlich. Auch wenn das natürlich ein Teil des Marketings ist. Die Grenze ist aber: Es sollte die Netze der Kunden nicht unsicherer machen, nur um der Produktzufriedenheit Willen.
Es gibt noch ein paar weitere Aspekte, die ich als junior-Netzwerker fragwürdig finde, so z.B. empfielt 3CX entgegen aller best-practise, die Telefonie im Produktiv-LAN (ganz unten im Link) zu lassen (aus Anwendungssicht nachvollziehbar, aus Netzwerksicht indiskutabel), aber das will ich hier jetzt nicht vertiefen.
Viele Grüße, commodity
ich habe endlich mal eine 3CX in die Finger bekommen. VoIP mache ich recht gern und üblicherweise verwende ich asterisk nativ, etwas eingelesen hatte ich mich aber schon vor einem guten Jahr in die 3CX. Diese habe ich nun bei einem Neukunden geerbt. Also Zeit, wieder was zu lernen. Von Euch
Die 3CX ist ja fürs KMU eher unspektakulär, aber recht easy zu bedienen. Die vorgefundene ist von einem 3CX-Partner eingerichtet worden, der auf seine Zertifizierung verweist (3CX CE, Sophos CA, CE). Meine Augen öffneten sich allerdings nicht unerheblich, als ich die Portfreigaben auf der Sophos ansah:
Die Sophos ist zur Anlage hin offen, wie ein Scheunentor: Ports 3479, 5000, 5001, 5060, 5061, 5090 9000-10999 sind freigegeben. Nun gibt es ja von 3CX eine hübsche Anleitung für die Firewalleinstellungen, die sicherlich vielen als Basis dient(e). Auch dem 3CX CE in meinem Fall, denke ich. Nach mehr als 15 Jahren mit Asterisk, das ohne eine einzige Freigabe für extern läuft, kommt man da schon ins Grübeln. Klar, 3CX hat einige Funktionen, die Zugriff von außen erfordern. Wenn man sie denn nutzt. Aber pauschal 5060, und 2000 Ports RTP?
Zumindest eine Betrachtung wert, denke ich. Der Reihe nach:
3CX: Für Ihren SIP-Trunk/VoIP-Provider
Öffnen Sie die folgenden Ports in Ihrer Firewall, damit die 3CX Anlage mit Ihrem VoIP-Anbieter/SIP-Trunk und per WebRTC kommunizieren kann:
5060, 5061 eingehend - für Kommunikation mit dem VOIP-Anbieter? - imo nicht erforderlich. Die Anlage registriert sich selbst (ausgehend) beim VoIP-Anbieter - über diesen Kanal kommt dann auch die eingehende Kommunikation. Ohne eingehende Freigabe.- Port 5060 (eingehend, UDP) und 5060–5061 (eingehend, TCP) zur Übertragung von SIP-Daten.
- Port 9000–10999 (eingehend, UDP) zur RTP-Kommunikation (Audio/eigentlicher Anruf).
9000-10999 eigehend für RTP vom VoIP-Anbieter? - imo ebenso nicht erforderlich. Das interne Endgerät aka Telefon meldet den/die gewünschten RTP-Ports an die Anlage und diese übermittelt die Ports an die Gegenstelle. Wenn jetzt symmetrisches RTP verwendet wird und die Firewall damit umgehen kann, öffnet also auch hier das Endgerät faktisch die benötigten Ports. Eingehende Freigaben nicht erforderlich.
Was mich irritiert: Warum kommuniziert 3CX das so? Auf mich wirkt das so als opferte man hier den Schutz einer zentralen Hardware-Firewall sehenden Auges, um den Betrieb des eigenen Produktes möglichst "reibungslos" zu ermöglichen. Oder gibt es aus Eurer Sicht andere Gründe, diese Ports für die Kommunikation zum VoIP-Anbieter zu öffnen. Dann her damit
Klar ist, wenn ich Geräte von außen ranhänge, brauche ich Ports. Dann natürlich auch RTP, wenn ein externes Telefon mit der Anlage arbeiten möchte. Solche Setups sind nicht unüblich, aber im KMU-Umfeld eher selten. Und das würde ja eher unter dem Punkt "Anbindung externer Geräte" stehen, nicht unter Kommunikation "mit Ihrem VoIP-Anbieter". Und man würde doch auch die Source beschränken... Oder ein VPN nutzen.
3CX: Für externe 3CX Applikationen und den 3CX SBC
Öffnen Sie die folgenden Ports, damit Benutzer die 3CX Applikationen für Android, iOS, macOS oder Microsoft Windows auch außerhalb des Unternehmensnetzwerks nutzen können:
Hier gehe ich (ohne vertiefte Betrachtung) mit: Die Anbindung externer Geräte benötigt Ports. Allerdings natürlich nur für die benötigten Dienste. Ich habe z.B. bei der übernommenen Anlage keinen SBC gesehen. Port 5090 ist dennoch freigegeben. Als Firewallbetreuer wünschte ich mir, gerichtet auch an die sog. Systempartner, den klareren Hinweis, dass Freigaben wohlüberlegt und -abgewogen sein sollten. Nicht alle Telefoniebetreuer sind fit im Firewalling.- Port 5090 (eingehend, UDP und TCP) für den 3CX Tunnel
- Port 443 oder 5001 (eingehend, TCP, HTTPS) für Präsenzanzeige und Telefon-Provisionierung; alternativ der von Ihnen festgelegte HTTPS-Port
- Port 443 (ausgehend, TCP) für Push-Benachrichtigungen von Google Android
- Port 443, 2197 und 5223 (ausgehend, TCP) für Push-Benachrichtigungen von Apple iOS
3CX: Für 3CX Videokonferenzen
Damit Sie Videokonferenzen erstellen und daran teilnehmen können, muss der von 3CX gehostete Cloud-Dienst an die 3CX Telefonanlage angebunden werden. Zur Kommunikation zwischen Anlage und Dienst müssen Sie folgende Ports freigeben:
Keine Beanstandung meinerseits - Port 443 (eingehend, TCP) zur Anbindung von Konferenzteilnehmern an die 3CX Telefonanlage
Zusammen fassend kann man sicher darüber diskutieren, ob die Freigabe einer Portrange (auf einen einzelnen Server) per se ein Sicherheitsrisiko darstellt, zumal 3CX imo ein Konfigurationstool für die jeweilige Gerätefirewall mitliefert. Aber 5060 am WAN ohne Not(wendigkeit) offen - im Installationsbeispiel hier sogar ohne Source-Adress-Beschränkung - das macht mich sprachlos. Hier hängt die Sicherheit (u.U.) des gesamten Netzes am Ende am SIP-Passwort. Wenn ich richtig liege, wäre mein Vertrauen in einen Anbieter, der seinen Kunden derartige Empfehlungen gibt doch stark beeinträchtigt. Ich würde dann denken: Wer weiß, wie die in der Programmierung mit dem Thema Sicherheit verfahren?
Aber vielleicht seht Ihr das ja anders, ich freue mich ggf. auf etwaige Erläuterungen. Wie seht Ihr das?
Die Anlage ist ja sehr verbreitet und ich weiß, dass einige von Euch die 3CX (gern) verbauen. Und ich finde die Bedienung eingängig und die Vielzahl an Erläuterungen und Anleitungen des Anbieters im Web auf den ersten Blick vorbildlich. Auch wenn das natürlich ein Teil des Marketings ist. Die Grenze ist aber: Es sollte die Netze der Kunden nicht unsicherer machen, nur um der Produktzufriedenheit Willen.
Es gibt noch ein paar weitere Aspekte, die ich als junior-Netzwerker fragwürdig finde, so z.B. empfielt 3CX entgegen aller best-practise, die Telefonie im Produktiv-LAN (ganz unten im Link) zu lassen (aus Anwendungssicht nachvollziehbar, aus Netzwerksicht indiskutabel), aber das will ich hier jetzt nicht vertiefen.
Viele Grüße, commodity
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7205388016
Url: https://administrator.de/contentid/7205388016
Ausgedruckt am: 24.11.2024 um 08:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
ich stimme dir vollkommen zu, was 3CX da seit Jahren kommuniziert ist totaler Unsinn, es braucht überhaupt keine offenen Ports eingehend um eine lokale 3CX zu betreiben. Hab ich mehrmals installiert, läuft.
Warum die das immer noch behaupten... ich habe keine Ahnung.
Leider ist das sehr verbreitet. Ich zitiere mal Nintendos Empfehlung für die Switch Konsole, wenn man z.B. MarioKart im Multiplayer spielen will:
UDP wird später ergänzt.
Jo. Das wird sicherlich nötig sein... (Spoiler: Ist es nicht).
Gestern erst Bekanntschaft mit einer Software für Türschlösser (Hotelbereich) gemacht. Die brauchen angeblich zwingend einen offenen Port von außen, weil die Cloud die Verbindung zum Kunden herstellt, statt umgekehrt.
Obwohl ein Test-NetConnection erfolgreich war (und beim blocken auf dem Server nicht mehr), wollte der Hersteller 2 Stunden lang partout darauf raus, dass hier eine Firewall etwas blockieren muss.
Begeistert bin ich davon auch nicht, aber was will man machen...
Kunde will billig. Da kann man sagen: So nen Müll richte ich nicht ein, dann lässt er das von Anderen einrichten, die das so machen wie du das in der Sophos siehst. Oder du sagst: Ich würde dringend empfehlen das zu lassen, aus folgenden Gründen. Aber wenn du das unbedingt möchtest, dann auf eigenes Risiko. Unterschreibe hier, dass du das trotz meiner Warnung möchtest. Dann bleiben zumindest die Ports zu.
Gruß
Drohnald
ich stimme dir vollkommen zu, was 3CX da seit Jahren kommuniziert ist totaler Unsinn, es braucht überhaupt keine offenen Ports eingehend um eine lokale 3CX zu betreiben. Hab ich mehrmals installiert, läuft.
Warum die das immer noch behaupten... ich habe keine Ahnung.
Wer weiß, wie die in der Programmierung mit dem Thema Sicherheit verfahren?
Vermutlich genau so, wie du dir das vorstellst: https://www.golem.de/news/alarmstufe-orange-trojaner-in-3cx-software-bet ...Leider ist das sehr verbreitet. Ich zitiere mal Nintendos Empfehlung für die Switch Konsole, wenn man z.B. MarioKart im Multiplayer spielen will:
Geben Sie den Start- und Endport zur Weiterleitung ein. Bei der Nintendo Switch-Konsole sind das die Ports 1024 bis 65535.
UDP wird später ergänzt.
Jo. Das wird sicherlich nötig sein... (Spoiler: Ist es nicht).
Gestern erst Bekanntschaft mit einer Software für Türschlösser (Hotelbereich) gemacht. Die brauchen angeblich zwingend einen offenen Port von außen, weil die Cloud die Verbindung zum Kunden herstellt, statt umgekehrt.
Obwohl ein Test-NetConnection erfolgreich war (und beim blocken auf dem Server nicht mehr), wollte der Hersteller 2 Stunden lang partout darauf raus, dass hier eine Firewall etwas blockieren muss.
Begeistert bin ich davon auch nicht, aber was will man machen...
Kunde will billig. Da kann man sagen: So nen Müll richte ich nicht ein, dann lässt er das von Anderen einrichten, die das so machen wie du das in der Sophos siehst. Oder du sagst: Ich würde dringend empfehlen das zu lassen, aus folgenden Gründen. Aber wenn du das unbedingt möchtest, dann auf eigenes Risiko. Unterschreibe hier, dass du das trotz meiner Warnung möchtest. Dann bleiben zumindest die Ports zu.
Gruß
Drohnald
1
Hi,
auch sehr lange im Einsatz gehabt. Nach dieser Vollkatastrophe, welche selbst verschuldet war durch eine Trader Software auf einem Mitarbeiter PC habe ich 3CX den Rücken zugekehrt.
Da scheint Sicherheit wirklich nicht so ernst genommen zu werden.
Auch die Kommunikation, während dem ganzen Fall, war mehr als fraglich. Selbst wenn man da jetzt nachgebessert hat.
In meinen Augen ein Musterbeispiel, wie man es nicht machen sollte.
Grüße
auch sehr lange im Einsatz gehabt. Nach dieser Vollkatastrophe, welche selbst verschuldet war durch eine Trader Software auf einem Mitarbeiter PC habe ich 3CX den Rücken zugekehrt.
Da scheint Sicherheit wirklich nicht so ernst genommen zu werden.
Auch die Kommunikation, während dem ganzen Fall, war mehr als fraglich. Selbst wenn man da jetzt nachgebessert hat.
In meinen Augen ein Musterbeispiel, wie man es nicht machen sollte.
Grüße
1
Hallo,
Auf folgender Seite von 3CX werden die Firewallanforderungen etwas detaillierter beschrieben: https://www.3cx.com/blog/voip-howto/firewall-nat-pat-stun/
Man beachte das „yes - if“. Wenn das „if“ nicht zutrifft, muss man den Port auch nicht freigeben.
Grüße
lcer
Auf folgender Seite von 3CX werden die Firewallanforderungen etwas detaillierter beschrieben: https://www.3cx.com/blog/voip-howto/firewall-nat-pat-stun/
Man beachte das „yes - if“. Wenn das „if“ nicht zutrifft, muss man den Port auch nicht freigeben.
Grüße
lcer
1
Danke für Euren Input!
Was mich irritiert ist: Es kann ja auch nicht im langfristigen Interesse des Marketings sein, wenn die Kunden ständigen Angriffen ausgesetzt werden. Selbst wenn nur einzelne durchschlagen.
@icer00: Prima Link. Leider schreiben sie es dort imo auch wieder falsch oder zumindest missverständlich:
Viele Grüße, commodity
Was mich irritiert ist: Es kann ja auch nicht im langfristigen Interesse des Marketings sein, wenn die Kunden ständigen Angriffen ausgesetzt werden. Selbst wenn nur einzelne durchschlagen.
@icer00: Prima Link. Leider schreiben sie es dort imo auch wieder falsch oder zumindest missverständlich:
UDP & TCP 5060 SIP Port Yes – if you intend on using VoIP Providers, WebRTC and Remote Extensions that are NOT using the 3CX Tunnel Protocol
Der erste Fall, also : "if you intend on using VoIP Providers, ... that are NOT using the 3CX Tunnel Protocol" dürfte unzutreffend sein. Es mag Szenarien geben, im Normalfall benötigt die Verbindung zum VoIP-Provider keinerlei Portforwarding beim Kunden. Einzig sollte man auf die Keepalives für die ausgehende Verbindung achten.Viele Grüße, commodity
Auf folgender Seite von 3CX werden die Firewallanforderungen etwas detaillierter beschrieben: https://www.3cx.com/blog/voip-howto/firewall-nat-pat-stun/
Das ist aber ein Blog aus 2010, den sicherlich niemand lies, wenn es ein Adminhandbuch gibt.
Selbst wenn, auch in dem Blog steht für 5060 TCP und 9000-9500 UDP
Yes – if you intend on using remote extensions or a VoIP Provider
Folglich behauptet 3CX, dass diese Ports zwingend eingehende frei sein müssen, wenn man einen VoIP Provider nutzt.Hier das Adminhandbuch in aktueller Fassung:
https://www.3cx.de/docs/adminhandbuch/firewall-router-konfiguration/
Dort steht ganz klar:
Für Ihren SIP-Trunk/VoIP-Provider
Öffnen Sie die folgenden Ports in Ihrer Firewall, damit die 3CX Anlage mit Ihrem VoIP-Anbieter/SIP-Trunk und per WebRTC kommunizieren kann:
Öffnen Sie die folgenden Ports in Ihrer Firewall, damit die 3CX Anlage mit Ihrem VoIP-Anbieter/SIP-Trunk und per WebRTC kommunizieren kann:
Port 5060 (eingehend, UDP) und 5060–5061 (eingehend, TCP) zur Übertragung von SIP-Daten.
Port 9000–10999 (eingehend, UDP) zur RTP-Kommunikation (Audio/eigentlicher Anruf). Für jeden Anruf sind zwei RTP-Ports erforderlich: ein Port zur Anrufsteuerung und ein weiterer zur Übertragung der Anrufdaten. Sollen mehrere Anrufe gleichzeitig erfolgen, muss somit stets die doppelte Anzahl an offenen Ports verfügbar sein.
Port 9000–10999 (eingehend, UDP) zur RTP-Kommunikation (Audio/eigentlicher Anruf). Für jeden Anruf sind zwei RTP-Ports erforderlich: ein Port zur Anrufsteuerung und ein weiterer zur Übertragung der Anrufdaten. Sollen mehrere Anrufe gleichzeitig erfolgen, muss somit stets die doppelte Anzahl an offenen Ports verfügbar sein.
Da ist sogar ein Bild dabei welches zeigt, dass der SIP-Provider diese Ports in Richtung 3CX nutzt, durch das NAT hindurch.
Wenn man außerordentlich freundlich wäre, könnte man vll. hineininterpretieren, dass dort nicht steht: 5060 muss auf jeden Fall offen sein. Aber ganz ehrlich: Jeder ohne entsprechenden Hintergrund würde die Ports nach dieser Anleitung öffnen und an die 3CX weiterleiten.
... zumal nur für WebRTC ein "only" davor gesetzt wurde.
(Bild aus: https://www.3cx.de/docs/adminhandbuch/firewall-router-konfiguration/)
Viele Grüße, commodity
Viele Grüße, commodity
Ohne es zu verharmlosen. Ich denke bei den ersten zwei Ports also 5060 und dann halt mit RTP Bereich ist kein Portforwarding gemeint, sondern dass man auf der Firewall die Kommunikation über diese Ports erlaubt. das wäre dann ja ok und notwendig. bzw halt nur notwendig wenn man zB nur 443 über einen transparenten Proxy erlaubt. Und ja, bei KMUs eher selten, und verleitet den gemeinen Admin zu einem Portforwarding.
leider sind gerade die alten Hasen aus dem ISDN Bereich mit IP oft total überfordert. hatten letzte Woche aich den Fall dass ein Kunde von ISDN auf SIP umgestellt wurde (ex Siemens Anlage). Vorraussetzung war aich ein Portforwarding für 5060 und RTP.
Auf die Frage warum, und was das für einen Sinn macht kam nur ein "weils so gehört und ich kenn wohl mit SIP nicht so aus". Und wenn wir es nicht machen, gibts keine Garantie dass es dann funktioniert, und wenns Probleme gibt ist es dann das Problem des Kunden.
GF meinte ich soll das tun was der "Spezialist" sagt und basta.
Habe es dann so eingerichtet und rd schriftlich mit meinen Bedenken an beide gesendet. Tja, was soll man sagen.
leider sind gerade die alten Hasen aus dem ISDN Bereich mit IP oft total überfordert. hatten letzte Woche aich den Fall dass ein Kunde von ISDN auf SIP umgestellt wurde (ex Siemens Anlage). Vorraussetzung war aich ein Portforwarding für 5060 und RTP.
Auf die Frage warum, und was das für einen Sinn macht kam nur ein "weils so gehört und ich kenn wohl mit SIP nicht so aus". Und wenn wir es nicht machen, gibts keine Garantie dass es dann funktioniert, und wenns Probleme gibt ist es dann das Problem des Kunden.
GF meinte ich soll das tun was der "Spezialist" sagt und basta.
Habe es dann so eingerichtet und rd schriftlich mit meinen Bedenken an beide gesendet. Tja, was soll man sagen.
Doch, die meinen eindeutig Portforwarding.
Der zweite Satz in der verlinkten Anleitung lautet:
Dann gibt es extra Links mit Schritt-für-Schritt Anleitungen für "die gängigsten Firewalls". Auf Platz 3: Fritz!Box.
Dort steht wörtlich:
Das Beispiel endet mit diesem Screenshot:
Selbiges natürlich für alle Anleitung bei den Firewalls.
Der zweite Satz in der verlinkten Anleitung lautet:
Nachfolgend erhalten Sie einen grundlegenden Überblick über Ports, die in Ihrer Firewall geöffnet sein/statisch weitergeleitet werden müssen.
Dann gibt es extra Links mit Schritt-für-Schritt Anleitungen für "die gängigsten Firewalls". Auf Platz 3: Fritz!Box.
Dort steht wörtlich:
Schritt 1: Konfigurieren der Port-Weiterleitung (NAT)
Das Beispiel endet mit diesem Screenshot:
Selbiges natürlich für alle Anleitung bei den Firewalls.
Zustimmung. Die meinen Portforwarding, der Wortlaut aus der Anleitung ist ja klar:
Was Kollege @rickstinson wohl meint ist, dass der, der das geschrieben hat, vielleicht gar nicht so recht wusste, was er da schreibt und eigentlich das meinte, was nötig ist, nämlich Freigabe outbound.
Das ist hier imo die Kernfrage: Sind die wirklich so ahnungslos oder geht es schlicht darum, die Anlage schon vorab für jeden möglichen usecase zu öffnen, um das "Kundenerlebnis" sicherzustellen und sich selbst von Supportanfragen zu "befreien".
Ich fürchte, letzteres. Ist doch so. Wird die Firewall auf die genutzten Features zugeschnitten, kommt nach 12 Monaten irgendeiner auf die Idee, dieses und jenes Feature wäre auch noch schön. Das wird dann angeklickt - und geht erstmal nicht. An die Firewall denkt dann keiner, sondern man ruft den 3CX-Support an und kostet deren Geld. Die nervt das und sagen sich: Dann lieber gleich "freie Fahrt". Den Hack kann man ggf. leicht dem Kunden zuschieben, denn er hat im Zweifel ja das weake Passwort verwendet.
wollen sie nicht. Das steht wohl fest.
Wer sind denn die Spezialisten für die Firewall? Doch wohl die Systembetreuer, die jeden Tag ihre Firewalls einrichten und monitoren und vor allem das ganze System im Blick haben. Nicht nur eine Anwendung oder einen Usecase.
Gestern bei einem Neukunden zum ersten Mal ins AD geguckt:
Die GPO hat der Spezialist für Praxisverwaltungssoftware gemacht. So viel zu den Spezialisten. Die wollen das ihr Ding läuft. Sind halt speziell im Denken.
Viele Grüße, commodity
Port 5060 (eingehend, UDP) und 5060–5061 (eingehend, TCP)
Was Kollege @rickstinson wohl meint ist, dass der, der das geschrieben hat, vielleicht gar nicht so recht wusste, was er da schreibt und eigentlich das meinte, was nötig ist, nämlich Freigabe outbound.
Das ist hier imo die Kernfrage: Sind die wirklich so ahnungslos oder geht es schlicht darum, die Anlage schon vorab für jeden möglichen usecase zu öffnen, um das "Kundenerlebnis" sicherzustellen und sich selbst von Supportanfragen zu "befreien".
Ich fürchte, letzteres. Ist doch so. Wird die Firewall auf die genutzten Features zugeschnitten, kommt nach 12 Monaten irgendeiner auf die Idee, dieses und jenes Feature wäre auch noch schön. Das wird dann angeklickt - und geht erstmal nicht. An die Firewall denkt dann keiner, sondern man ruft den 3CX-Support an und kostet deren Geld. Die nervt das und sagen sich: Dann lieber gleich "freie Fahrt". Den Hack kann man ggf. leicht dem Kunden zuschieben, denn er hat im Zweifel ja das weake Passwort verwendet.
GF meinte ich soll das tun was der "Spezialist" sagt und basta.
Genau das sind oft die Folgen. U.a. deshalb habe ich auch den langen Post gemacht. Die vermeintlichen "Spezialisten" sind eben keine. Vielleicht können die gut Telefonie, vielleicht gut Marketing. Aber Firewall können oder (besser wollen sie nicht. Das steht wohl fest.Wer sind denn die Spezialisten für die Firewall? Doch wohl die Systembetreuer, die jeden Tag ihre Firewalls einrichten und monitoren und vor allem das ganze System im Blick haben. Nicht nur eine Anwendung oder einen Usecase.
Gestern bei einem Neukunden zum ersten Mal ins AD geguckt:
GPO für alle Clients:
"Firewall deaktivieren"
und die machte genau das. Seit 2018 hat das, trotz zwischenzeitlich anderer Betreuung, niemand gemerkt. Bei den Sicherheitseinstellungen war alles grün "Firewall deaktivieren"
Die GPO hat der Spezialist für Praxisverwaltungssoftware gemacht. So viel zu den Spezialisten. Die wollen das ihr Ding läuft. Sind halt speziell im Denken.
Viele Grüße, commodity
Kleiner Nachtrag für 3CX-Interessierte:
Zeitlich nach obiger Diskussion gab es mal wieder eine Schwachstelle, hier vom Kollegen @kgborn dargestellt.
Bemerkenswert ist der Umgang von 3CX mit der Schwachstellenmeldung:
Im Kontext dieser Peinlichkeit versuchte man sich bei 3CX offenbar in "security by obscurity", wobei "Gegner" hier der Kunde war, nicht etwa die Sicherheitslücke. Der bemerkenswerte Vorgang ist vom Kollegen @kgborn hier beschrieben:
https://www.borncity.com/blog/2023/12/31/die-3cx-mysql-sicherheitslcke-u ...
Das kleinkarierte Niveau dieses Unternehmens gipfelt dann darin, dass der sachlich kritisierende User von 3CX rausgeworfen wurde, und zwar offenbar vom CEO höchstpersönlich:
Ist das ein Erfolg der Digitalisierung, dass man seine zentrale Unternehmenskommunikation heutzutage in die Hände solcher Anbieter legt? Wie abgestumpft kann man sein?
Viele Grüße, commodity
Zeitlich nach obiger Diskussion gab es mal wieder eine Schwachstelle, hier vom Kollegen @kgborn dargestellt.
Bemerkenswert ist der Umgang von 3CX mit der Schwachstellenmeldung:
Nachdem die Schwachstelle durch Zufall bekannt wurde, versuchte man bei 3CX jemanden zu kontaktieren, um ein "responsible disclosure" einzuleiten. Der 3CX Customer Support wollte eine Lizenznummer wissen – da fasst Du dich doch an den Kopf.
Der Entdecker hat sich dann an CERT/CC gewandt und einen Fall eröffnet, weil eine Sicherheitslücke eine Sicherheitslücke bleibt, auch wenn man keine Lizenznummer kennt.
Lange Rede kurzer Sinn: Auch CERT/CC gelang es nicht, einen Kontakt zu 3CX herzustellen. Die weiteren Kontaktversuche des Entdeckers verliefen ebenfalls im Sande.
Mit der Folge, dass die Schwachstelle schließlich veröffentlicht wurde, bevor gepatcht wurde.Der Entdecker hat sich dann an CERT/CC gewandt und einen Fall eröffnet, weil eine Sicherheitslücke eine Sicherheitslücke bleibt, auch wenn man keine Lizenznummer kennt.
Lange Rede kurzer Sinn: Auch CERT/CC gelang es nicht, einen Kontakt zu 3CX herzustellen. Die weiteren Kontaktversuche des Entdeckers verliefen ebenfalls im Sande.
Im Kontext dieser Peinlichkeit versuchte man sich bei 3CX offenbar in "security by obscurity", wobei "Gegner" hier der Kunde war, nicht etwa die Sicherheitslücke. Der bemerkenswerte Vorgang ist vom Kollegen @kgborn hier beschrieben:
https://www.borncity.com/blog/2023/12/31/die-3cx-mysql-sicherheitslcke-u ...
Das kleinkarierte Niveau dieses Unternehmens gipfelt dann darin, dass der sachlich kritisierende User von 3CX rausgeworfen wurde, und zwar offenbar vom CEO höchstpersönlich:
Ist das ein Erfolg der Digitalisierung, dass man seine zentrale Unternehmenskommunikation heutzutage in die Hände solcher Anbieter legt? Wie abgestumpft kann man sein?
Viele Grüße, commodity
