5
Ist ein Session Border Controller bei Voip zwingend wichtig für die Sicherheit?
Hallo zusammen,
Wir stellen dem,nächst mit unserer TK Anlage (Unify) von PMX auf IP um und integrieren Teams.
Nun sagte mir der TK-Dienbstleister, dass wir für die Aufbrechung der SIP-Pakete zwingend einen SBC benötigen, um für Sicherheit zu sorgen.
Wenn ich das richtig sehe, gibt es bei unserer Sophos UTM da nur rudimentären Schutz.
Was sagt Ihr dazu?`Habt Ihr eine SBC zusätzlich vor der TK-Anlage? Der SBC ist ja gar nicht so günstig.
Vielen Dank!
Wir stellen dem,nächst mit unserer TK Anlage (Unify) von PMX auf IP um und integrieren Teams.
Nun sagte mir der TK-Dienbstleister, dass wir für die Aufbrechung der SIP-Pakete zwingend einen SBC benötigen, um für Sicherheit zu sorgen.
Wenn ich das richtig sehe, gibt es bei unserer Sophos UTM da nur rudimentären Schutz.
Was sagt Ihr dazu?`Habt Ihr eine SBC zusätzlich vor der TK-Anlage? Der SBC ist ja gar nicht so günstig.
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 606956
Url: https://administrator.de/contentid/606956
Printed on: April 19, 2024 at 13:04 o'clock
5 Comments
Latest comment
Ich würde auf einen Fall einen SBC empfehlen. Eine Firewall könnte sich als ein Störfaktor erweisen. Es ist auch so, zumindest bei der Telekom im Business-Bereich, dass der SBC eine eigene verschlüsselte Leitung bekommt und diese dann nur VoIP macht.
Moin,
ja, ein SBC sollte schon sein... Das geht aber auch als OpenSource... https://www.kamailio.org/w/features/
Je nachdem, wie es mit dem Know-How, etc. so ausschaut.
VG
ja, ein SBC sollte schon sein... Das geht aber auch als OpenSource... https://www.kamailio.org/w/features/
Je nachdem, wie es mit dem Know-How, etc. so ausschaut.
VG
Hi,
das hängt natürlich von eurem Sicherheitsbedürfnis und der Komplexität der Infrastruktur ab. In einer typischen "Sophos-UTM-Umgebung", sprich KMU mit geringen bis durchschnittlichen Sicherheitsanforderungen, ist es eher fernliegend, einen dedizierten SBC zu betreiben.
Wenn, wie in der anderen Antwort angesprochen, einer eigener VoIP-Link gekauft wird, dann bekommst Du in der Regel ohnehin ein Modem-Router-Gerät, das "SBC-Funktion" hat (mehr oder weniger schmalspurig), weil der Anbieter damit sein Netz terminieren möchte. Auch ansonsten (via Internet oder WAN-seitiges VLAN des Internetanbieters) enthalten die von KMU bei VoIP-Anbietern eingekauften Leistungen das Proxying, also ihr werdet extern niemals P2P kommunizieren, sondern mit dem SBC eures Providers.
Der Dienstleister scheint mehr eine Verunsicherungsstrategie zu fahren bzw. sollte näher ausführen können, welche Pakete wohin aus welchem Grund "aufgebrochen" werden sollen, weil eine Flow-basierte Selektion nicht reichen würde.
Grüße
Richard
das hängt natürlich von eurem Sicherheitsbedürfnis und der Komplexität der Infrastruktur ab. In einer typischen "Sophos-UTM-Umgebung", sprich KMU mit geringen bis durchschnittlichen Sicherheitsanforderungen, ist es eher fernliegend, einen dedizierten SBC zu betreiben.
Wenn, wie in der anderen Antwort angesprochen, einer eigener VoIP-Link gekauft wird, dann bekommst Du in der Regel ohnehin ein Modem-Router-Gerät, das "SBC-Funktion" hat (mehr oder weniger schmalspurig), weil der Anbieter damit sein Netz terminieren möchte. Auch ansonsten (via Internet oder WAN-seitiges VLAN des Internetanbieters) enthalten die von KMU bei VoIP-Anbietern eingekauften Leistungen das Proxying, also ihr werdet extern niemals P2P kommunizieren, sondern mit dem SBC eures Providers.
Der Dienstleister scheint mehr eine Verunsicherungsstrategie zu fahren bzw. sollte näher ausführen können, welche Pakete wohin aus welchem Grund "aufgebrochen" werden sollen, weil eine Flow-basierte Selektion nicht reichen würde.
Grüße
Richard
Moin,
Alle Punkte waren aus meiner Sicht bisher bei der Telefonie über PMX kein Thema und damit simpel, übersichtlich, verständlich gehalten.
Ein SBC bringt so ein großes Stück Einfachheit zurück und natürlich auch Sicherheit (Verschlüsselung, TLS Zertifikate, S2M Schnittstelle, kein IP Datenfluss durch die DMZ, etc...). Natürlich muss ein SBC auch gewartet werden - keine Frage.
Gruß,
Dani
In einer typischen "Sophos-UTM-Umgebung", sprich KMU mit geringen bis durchschnittlichen Sicherheitsanforderungen, ist es eher fernliegend, einen dedizierten SBC zu betreiben
ich sehe bei solchen Szenarien immer folgende Punkte:- Änderungen an dem Regelwerk können dazu führen, dass es Probleme mit der Telefonie oder sogar ein Ausfall gibt.
- Bei Installation von Patches oder neue Firmwareversionen hast du zukünftig auch einen Ausfall der Telefonie.
- Je nach Design und Auslastung der Geräte und Internetleitungen ist über QoS und Traffic-Shapping nachzudenken.
- Mögliche DDoS oder Angriffsvektoren auf die Telefonie. Sprich IDS/IPS müssten entsprechend konfiguriert und überwacht werden.
Alle Punkte waren aus meiner Sicht bisher bei der Telefonie über PMX kein Thema und damit simpel, übersichtlich, verständlich gehalten.
Ein SBC bringt so ein großes Stück Einfachheit zurück und natürlich auch Sicherheit (Verschlüsselung, TLS Zertifikate, S2M Schnittstelle, kein IP Datenfluss durch die DMZ, etc...). Natürlich muss ein SBC auch gewartet werden - keine Frage.
Gruß,
Dani
Moin zusammen,
kurz zum Hintergrund: die Umstellung von PMX sowie ISDN auf VoIP haben wir auch hinter uns (wie zwangsweise sicherlich viele andere auch). Bei uns (18 Standorte, 1100 User) ist die TK-Anlage von Alcatel-Lucent, der SBC von AudioCodes und die "SIP-Trunks Pure" von der Telekom (letzteres nur mit Bauchschmerzen zu empfehlen). Insbesondere der SBC spielt dabei eine wichtige Rolle, wenn es um die Anpassung von Parametern innerhalb von SIP oder RTP geht. Warum?
Beispiel Notrufe 110 / 112: basierend auf der Ortskennziffer (Vorwahl) wird die nächste Polizei- / Rettungsleitstelle lokalisiert und verbunden. Den Teil der Rufnummernbildung kann noch die TK-Anlage erledigen. Aber welches der drei (oder mehr) Felder des SIP-Pakets wertet der Provider aus, um die Ortskennziffer zu extrahieren und dann entsprechend weiter zu behandeln?
Über sog. "Manipulation Rules" kann man den SBC die entsprechenden Werte in die jeweiligen Felder eintragen oder verändern lassen. Der Leistungsumfang hört damit jedoch nicht auf. Die von @Dani erwähnte Einfachheit von ISDN / PMX ist mit VoIP im Grunde genommen beerdigt worden, da jeder Provider sein eigenes VoIP-Süppchen kocht. Die erste Inbetriebnahme verkompliziert sich unter Umständen deutlich. Entsprechend ergibt sich (zumindest im Anlagenumfeld) der Bedarf nach individueller Anpassung der nun IP-basierten Pakete. Im Gegensatz zu einer UTM-Firewall (oder Next Generation Firewall oder meinetwegen auch noch Application Layer Gateway) kann ein SBC dies um Längen besser. Welche Aufgaben er konkret übertragen bekommt, ist von der Infrastruktur, den Anforderungen und dem angedachten Design abhängig. Richtig umgesetzt, gewinnt man jedoch tatsächlich einen nicht unerheblichen Teil der früheren Einfachheit zurück. Dieser initiale Mehraufwand kostet insbesondere dann ein paar graue Haare, wenn die Infos vom Provider nun ja... ausbaufähig sind. Auch Anpassungen danach sind an einer Stelle pfleg- und einsehbar.
Unterm Strich würde ich persönlich im kommerziellen / professionellen Umfeld nicht ohne SBC arbeiten wollen. Privat sieht die Sache natürlich wieder anders aus und bei "ganz kleinen Firmen mit einer FritzBox" ist es eine Frages Kosten-/Nutzenverhältnisses sowie des gewünschten Leistungsumfangs.
Ich habe einen ähnlichen Eindruck wie @c.r.s., wobei auch schlicht "nur" eine schlechte Formulierung gewählt worden sein könnte. "für Sicherheit sorgen" kann alles und nichts bedeuten.
In unserem Fall steht der SBC als VM im eigenen Netz und reicht die Registrierung der SIP-Trunks von der TK-Anlage lediglich weiter. Bei der Migration haben wir festgestellt, dass die Firewall eine ALG-Komponente beinhaltete, die zusätzlich noch an den VoIP-Paketen rumgebastelt hat und erst nach einem Reset die alten Parameter vergessen wollte. Das Verhalten bzw. daraus resultierende Phänomen wäre aber wohl auch aufgetreten, wenn der SBC vor der Firewall gestanden hätte.
Die von dir genannten Punkte treffen samt und sonders zu und darüber haben wir auch etwas länger gebrütet. Systemimanente Schwachstellen...
Zum Thema IDS / IPS: In die VoIP-Pakete kann man beliebige Daten eintragen. Wieder so eine systemimanente Sache, die ein Angreifer in unserem Fall genutzt hat, um die SIP-Trunks bzw. die Anzahl gebuchter gleichzeitiger Verbindungen zu blockieren. Da der Angriff beim Provider auflief, waren wir machtlos. Ein wenig Analyse, Einschalten der Strafverfolgungsbehörden sowie des Providers und viel Geduld waren alles, was wir beitragen konnten.
kurz zum Hintergrund: die Umstellung von PMX sowie ISDN auf VoIP haben wir auch hinter uns (wie zwangsweise sicherlich viele andere auch). Bei uns (18 Standorte, 1100 User) ist die TK-Anlage von Alcatel-Lucent, der SBC von AudioCodes und die "SIP-Trunks Pure" von der Telekom (letzteres nur mit Bauchschmerzen zu empfehlen). Insbesondere der SBC spielt dabei eine wichtige Rolle, wenn es um die Anpassung von Parametern innerhalb von SIP oder RTP geht. Warum?
Beispiel Notrufe 110 / 112: basierend auf der Ortskennziffer (Vorwahl) wird die nächste Polizei- / Rettungsleitstelle lokalisiert und verbunden. Den Teil der Rufnummernbildung kann noch die TK-Anlage erledigen. Aber welches der drei (oder mehr) Felder des SIP-Pakets wertet der Provider aus, um die Ortskennziffer zu extrahieren und dann entsprechend weiter zu behandeln?
Über sog. "Manipulation Rules" kann man den SBC die entsprechenden Werte in die jeweiligen Felder eintragen oder verändern lassen. Der Leistungsumfang hört damit jedoch nicht auf. Die von @Dani erwähnte Einfachheit von ISDN / PMX ist mit VoIP im Grunde genommen beerdigt worden, da jeder Provider sein eigenes VoIP-Süppchen kocht. Die erste Inbetriebnahme verkompliziert sich unter Umständen deutlich. Entsprechend ergibt sich (zumindest im Anlagenumfeld) der Bedarf nach individueller Anpassung der nun IP-basierten Pakete. Im Gegensatz zu einer UTM-Firewall (oder Next Generation Firewall oder meinetwegen auch noch Application Layer Gateway) kann ein SBC dies um Längen besser. Welche Aufgaben er konkret übertragen bekommt, ist von der Infrastruktur, den Anforderungen und dem angedachten Design abhängig. Richtig umgesetzt, gewinnt man jedoch tatsächlich einen nicht unerheblichen Teil der früheren Einfachheit zurück. Dieser initiale Mehraufwand kostet insbesondere dann ein paar graue Haare, wenn die Infos vom Provider nun ja... ausbaufähig sind. Auch Anpassungen danach sind an einer Stelle pfleg- und einsehbar.
Unterm Strich würde ich persönlich im kommerziellen / professionellen Umfeld nicht ohne SBC arbeiten wollen. Privat sieht die Sache natürlich wieder anders aus und bei "ganz kleinen Firmen mit einer FritzBox" ist es eine Frages Kosten-/Nutzenverhältnisses sowie des gewünschten Leistungsumfangs.
Zitat von @Leo-le:
Nun sagte mir der TK-Dienbstleister, dass wir für die Aufbrechung der SIP-Pakete zwingend einen SBC benötigen, um für Sicherheit zu sorgen.
Wenn ich das richtig sehe, gibt es bei unserer Sophos UTM da nur rudimentären Schutz.
Zitat von @c.r.s.:
Der Dienstleister scheint mehr eine Verunsicherungsstrategie zu fahren bzw. sollte näher ausführen können, welche Pakete wohin aus welchem Grund "aufgebrochen" werden sollen, weil eine Flow-basierte Selektion nicht reichen würde.
Nun sagte mir der TK-Dienbstleister, dass wir für die Aufbrechung der SIP-Pakete zwingend einen SBC benötigen, um für Sicherheit zu sorgen.
Wenn ich das richtig sehe, gibt es bei unserer Sophos UTM da nur rudimentären Schutz.
Zitat von @c.r.s.:
Der Dienstleister scheint mehr eine Verunsicherungsstrategie zu fahren bzw. sollte näher ausführen können, welche Pakete wohin aus welchem Grund "aufgebrochen" werden sollen, weil eine Flow-basierte Selektion nicht reichen würde.
Ich habe einen ähnlichen Eindruck wie @c.r.s., wobei auch schlicht "nur" eine schlechte Formulierung gewählt worden sein könnte. "für Sicherheit sorgen" kann alles und nichts bedeuten.
Zitat von @Dani:
ich sehe bei solchen Szenarien immer folgende Punkte:
ich sehe bei solchen Szenarien immer folgende Punkte:
- Änderungen an dem Regelwerk können dazu führen, dass es Probleme mit der Telefonie oder sogar ein Ausfall gibt.
- Bei Installation von Patches oder neue Firmwareversionen hast du zukünftig auch einen Ausfall der Telefonie.
- Je nach Design und Auslastung der Geräte und Internetleitungen ist über QoS und Traffic-Shapping nachzudenken.
- Mögliche DDoS oder Angriffsvektoren auf die Telefonie. Sprich IDS/IPS müssten entsprechend konfiguriert und überwacht werden.
In unserem Fall steht der SBC als VM im eigenen Netz und reicht die Registrierung der SIP-Trunks von der TK-Anlage lediglich weiter. Bei der Migration haben wir festgestellt, dass die Firewall eine ALG-Komponente beinhaltete, die zusätzlich noch an den VoIP-Paketen rumgebastelt hat und erst nach einem Reset die alten Parameter vergessen wollte. Das Verhalten bzw. daraus resultierende Phänomen wäre aber wohl auch aufgetreten, wenn der SBC vor der Firewall gestanden hätte.
Die von dir genannten Punkte treffen samt und sonders zu und darüber haben wir auch etwas länger gebrütet. Systemimanente Schwachstellen...
Zum Thema IDS / IPS: In die VoIP-Pakete kann man beliebige Daten eintragen. Wieder so eine systemimanente Sache, die ein Angreifer in unserem Fall genutzt hat, um die SIP-Trunks bzw. die Anzahl gebuchter gleichzeitiger Verbindungen zu blockieren. Da der Angriff beim Provider auflief, waren wir machtlos. Ein wenig Analyse, Einschalten der Strafverfolgungsbehörden sowie des Providers und viel Geduld waren alles, was wir beitragen konnten.
