IP-Telefonie mit Session-Border-Controllern schützen
Wehrhaft
Risiken birgt die Telefonie nicht nur in Gestalt zwielichtiger Callcenter, sondern auch zunehmend auf der technischen Ebene: Mit der Digitalisierung wächst die Gefahr von Angriffen über das Internet.
Wegen der Umstellung der öffentlichen ISDN- auf IP-Telefonienetze stellt sich oft heraus, dass Firewalls die Telefonieanwender auf der Applikationsebene nicht ausreichend schützen. Dabei gibt es hier im Vergleich zu reinen Datennetzen diverse zusätzliche Angriffsvektoren, zum Beispiel Gebührenmissbrauch, Telephony Denial of Service (TDoS, etwa durch SIP-Flooding) und Identitätsmissbrauch durch Rufnummern-Spoofing.
Wer seine interne IP-Telefonie gegenüber öffentlichen Netzen öffnet, steigert das Gefährdungspotenzial enorm. Angreifer versuchen zum Beispiel, über Rufumleitungen auf Sonderdienste oder Auslandsnummern hohe Gebühren zu erzeugen. Da die Telekommunikation in Unternehmen und Behörden noch immer von zentraler Bedeutung ist, zieht ein Ausfall dieses Dienstes hohe Kosten und einen erheblichen Reputationsverlust nach sich.
Schützendes Gateway
Derlei Risiken kann ein Session-Border-Controller entgegenwirken (SBC), ein Gateway, das IP-Telefonienetze in unterschiedlichen Sicherheitszonen und an Vertrauensgrenzen miteinander koppelt. Netzwerkdesigns sehen meist die Einbindung von SBCs in ein mehrstufiges Firewall-Konzept vor. Sie kommen bei Bedarf außerdem zur Protokollanpassung zum Einsatz und koppeln unterschiedliche, sonst inkompatible IP-Telefoniesysteme miteinander. Typische Vertreter dieser Kategorie sind Mediant von Audiocodes, CUBE von Cisco oder SBC von Sonus.
Da die Telefonie oft gar nicht oder erst neuerdings in der jeweiligen IT-Abteilung angesiedelt ist, sind die applikationsspezifischen Gefährdungen und Besonderheiten noch wenig bekannt. Unternehmen und Behörden sind häufig der Ansicht, dass eine Stateful-Inspection-Firewall ausreicht. Bei der IP-Telefonie gibt es jedoch mehrere Datenströme für Sprache und Signalisierung, zum Beispiel für den Auf- und Abbau von Gesprächen und somit für das Call-Routing. Das erschwert eine Stateful Inspection. Internettelefonie-Serviceprovider (ITSP) stellen zur Signalisierung meist eine Schnittstelle auf Basis des Session Initiation Protocol (SIP) bereit. Dann funktioniert eine Übertragung sowohl mittels UDP als auch mittels TCP.
Verschlüsselte Internettelefonie
TCP ist die Voraussetzung für eine TLS-verschlüsselte Signalisierung. Anwender müssen das mit dem ITSP klären oder – falls vorhanden – in dessen Schnittstellendokumentation nachlesen, welche Transportprotokolle er anbietet. Der Transport des Medienstroms für die Sprachdaten erfolgt per Real-Time Transport Protocol (RTP) mit je einem Stream pro Kommunikationsrichtung. RTP nutzt dafür UDP-Datagramme. Die dafür benötigten Portinformationen werden in der Signalisierung übertragen, im Fall von SIP gemäß dem Session Description Protocol (SDP, siehe Abbildung 1).
Der Transport von Sprachdaten über NAT-Grenzen hinweg ist schwierig, da die Network Address Translation IP- und Portinformationen verändert. Ohne Anpassung der IP-Adressen und Ports an der NAT-Grenze kommt es zum sogenannten Dead-Air-Effekt: Es ist keine Sprachübertragung möglich, obwohl die Signalisierung erfolgreich war und die Verbindung zu stehen scheint. Das Real-Time Control Protocol verkompliziert die Sache zusätzlich: Die RTCP-Pakete enthalten Daten für das Qualitätsmonitoring. Es kommt jeweils eine UDP-Portnummer höher zur Anwendung als beim korrespondierenden RTP-Datenstrom.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) befasst sich ebenfalls in mehreren Veröffentlichungen mit der Absicherung von VoIP-Netzen mit dem SBC als zentralem Bestandteil (siehe ix.de/ix1811112). Es gilt hierbei zunächst zu ermitteln, welchen Schutzbedarf das betreffende VoIP-Netz hat.
SBCs gibt es je nach Hersteller, Modell, Funktionsumfang und Lizenzmodell in vielerlei Varianten (siehe auch den Kasten „Leistungsmerkmale“). Das BSI empfiehlt schon bei normalem Schutzbedarf ein dediziertes Gerät. In überschaubaren Netzen ist es laut Empfehlung immerhin möglich, auf eine dedizierte Firewall vor dem SBC zu verzichten, wenn der über eine integrierte Firewall verfügt. Eine Härtung des zugrunde liegenden Betriebssystems, also das Deaktivieren aller nicht benötigten Dienste, ist jedenfalls unabdingbar.