Sicherheitshinweise zur Konfiguration einer SwyxWare

Die SwyxWare ist als VoIP Telefonanlage, die mit dem Internet in Verbindung steht, potentiell in der Lage, durch nicht gewünschte Anrufe Kosten für den Betreiber zu verursachen. In diesem Artikel sollen einige potentielle Konfigurationsfehler mit der SwyxWare aufgeführt werden, und die Folgen, die sich daraus ergeben können. Dazu finden Sie hier Hinweise, wie Sie eine SwyxWare-Installation gegen solche Zugriffe "härten" können.

Zu jedem einzelnen Punkt gibt es mehr oder weniger ausführliche Erklärungen, um die Hintegründe klar zu machen und die Zusammenhänge zu verdeutlichen. Der Übersicht halber ist jeweils der Kernpunkt in Fettschrift markiert.

Sicherheitsratschläge zu SIP Anmeldungen und SwyxWare-Usern

1. Das Anmelden an einem SwyxWare-Benutzer kann entweder mit Windows-Authentifizierung oder durch Username/Password Kombinationen erfolgen. Dabei sollten zumindest die Passwörter nicht einfach zu erraten sein. Gerade für SIP Endgeräte (Mediapack, Dect-Anlagen, etc.) wird gerne die ganz einfache Variante verwendet: Rufnummer 100, Benutzername 100, SIP UserID 100, Passwort 100. Das ist generell kein Problem, es sei denn, jemand bekommt Zugang zum Netzwerk des Kunden. In diesem Fall kann er sehr schnell durch eine einfache Brute Force Attacke gültige Kombinationen austesten, und anschließend über die Anlage auf Kosten des Kunden Anrufe tätigen.
2. Port 5060 soll *niemals* direkt aus dem Internet ereichbar sein. Es gibt eine große Anzahl von Bot-Netzen, die das Internet permanent nach Anlagen durchsuchen, die auf Port 5060 ereichbar sind. Sobald eine solche Anlage gefunden wird, werden in großer Menge Brute Force Angriffe auf diese Adresse durchgeführt, um gültige Anmeldedaten zu finden. Wenn dann noch der Fehler aus Punkt 1) gemacht wurde, werden sich relativ schnell Bots als User an der SwyxWare anmelden und sie für potentiell kostenintensive Rufe ins Ausland benutzen.
3. Auch Port 5096 darf *nie* von extern erreichbar sein! Es handelt sich hier um den *internen* Call Control Port des Push Notification Dienstes (PNS). Auf diesem Port agiert der PNS als Proxy, der SIP Pakete direkt an den Serverdienst weitergibt. Eine Erreichbarkeit dieses Ports aus dem öffentlichen Internet hat also praktisch den gleichen Effekt, als wenn Port 5060 geöffnet wird.
4. Generell gilt: Aus dem öffentlichen Internet sollten nur die Ports erreichbar sein, die wirklich benötigt werden. Wenn bei der Planung der Weiterleitungen anhand unserer Portliste  Unklarheiten bestehen, hilft unser Serviceteam gerne weiter.
5. Wenn bei der Installation der SwyxWare das Feature "Automatische Vermittlung" mit installiert wird, legt der Konfigurationsassistent automatisch einen Benutzer "Zentrale" an und hinterlegt dort das Script für besagte Vermittlungsaufgaben.
   Der automatisch erzeugte Benutzer "Zentrale" sollte NICHT zur Anmeldung eines echten Nutzers verwendet werden. Das hinterlegte Script bietet einem Anrufer unter anderem die Möglichkeit, eine Zielrufnummer per DTMF einzugeben, an die man verbunden werden möchte.
   Wenn hier ein echter Nutzer angemeldet wird, dann wird meistens auch das Anrufrecht von "Zentrale" vom vorkonfigurierten "Interne Rufe" auf "Keine Rufbeschränkung" geändert, damit der Anwender auch nach extern telefonieren kann. Wenn dann aber das mitinstallierte Script weiterhin aktiv bleibt und im Callrouting aufgerufen werden kann, dann kann ein Anrufer sich auch wieder ins Amt durchverbinden lassen, was wiederum Kosten für den Betreiber verursacht.

Sicherheitsratschläge bezüglich SIP-Trunks

1. Die Botnetze, von denen oben bereits die Rede war, suchen mittlerweile nicht mehr nur nach dem Zielport 5060, sondern scannen auch komplette Portbereiche. Damit wird auch ein Linkmanager, der ja auf Port 65002 von extern erreichbar sein muss, früher oder später "entdeckt". Das kann abseits von Sicherheitsproblemen schon durch die reinen Scans zu Lastproblemen führen, je nach Kapazität der Internverbindung und Ausstattung der SwyxWare-Maschine. Es empfiehlt sich also, in der Firewall ankommende SIP Pakete nur von IP-Adressen aus zuzulassen, die auch den Proxies des entsprechenden SIP Providers gehören.
2. Bei vielen Providern ist es nötig, in der Trunkkonfiguration zusätzlich zu den Rufnummern auch noch SIP URIs zu konfigurieren. Diese liegen im einfachsten Fall in der Form <+49[Ortsvorwahl][Kopfnummer]*@*> vor. Wenn man mehrere komplett verschiedene Rufnummern hat, muss allerdings für jede Nummer eine komplett eigene URI angelegt werden, was natürlich mehr Aufwand bedeutet. Wir haben mehrere Fälle gesehen, in denen der Einfachheit halber eine URI mit dem Inhalt <*@*> angelegt wurde. Dadurch akzeptiert der Linkmanager jetzt JEDES ankommende INVITE Paket, egal ob die Zielrufnummer aus dem eigenen Rufnummernbereichen stammt oder nicht!
   Es gibt Botnetze, die keine Registrierungen versuchen, sondern einfach auf gut Glück INVITE Pakete schicken. Mit einer solchen "catch all URI" akzeptiert der Linkmanager solche INVITEs, was im "besten" Fall für zusätzliche Last auf dem System sorgt, weil jedes dieser Pakete komplett wie ein ganz normaler ankommender Ruf bearbeitet wird, bis der Server den Ruf als nicht zustellbar verwirft.
3. Nicht nur für User, sondern auch für Trunkgruppen wird eine Anrufberechtigung eingestellt. Bei Trunkgruppen ist die Standardeinstellung "Interne Rufe". Das wird leider oft falsch verstanden: Diese Einstellung bedeutet NICHT, dass über diesen Ruf nicht nach extern telefoniert werden kann. Vielmehr ist es so zu verstehen, dass die Trunks in dieser Trunkgruppe ankommende Rufe nur intern ZUSTELLEN dürfen. Stellt man hier auf einer Trunkgruppe "Keine Rufbeschränkung" ein, so erhalten ankommende Rufe auf Trunks in dieser Trunkgruppe das Recht, nach überallhin zugestellt zu werden, auch wieder nach extern! Eine solche Konfiguration ist nur nötig, wenn man direkt zwischen Trunks routen will, ohne die Rufe auf Benutzer zuzustellen. Ein Beispiel kann der Betrieb einer Unteranlage sein. In einem solchen Fall muss aber mit genau definierten Routing-Regeln gearbeitet werden, um zu Verhindern, dass die ankommenden Rufe auf anderen Amtsleitungen wieder zum Provider zurückgeschickt werden.
4. Der maximale Schaden wird mit einer Kombination der Fehler aus Punkt 2 und 3 angerichtet. Im Folgenden wird einmal Schritt für Schritt, was in diesem Fall passiert:
   - Ein INVITE kommt am Linkmanager an und enthält (Beispiel) als Ziel "+15556832@nowhere.com"
   - Der Linkmanager akzeptiert das INVITE dank der Catch-All URI <*@*>
   - Der Linkmanager gibt den Ruf zur Verarbeitung an den Serverdienst weiter
   - Der Serverdienst kennt die Nummer nicht, und sucht daher einen Weg, den Ruf weiterzuleiten
   - Alle nach extern führenden Trunkgruppen haben wie üblich den Weiterleitungseintrag für "+*"
   - Da der Ruf mit dem Recht "Keine Rufbeschränkung" ankam, wird er nach extern zugestellt.
   Ergebnis: Die SwyxWare wird als offenes SIP Relais benutzt, um ohne irgendeine Form der Anmeldung internationale Rufe auf Kosten des Betreibers der Anlage zu machen.
   

Generelle Sicherheitshinweise zur SwyxWare

1. Der Konfigurationsassistent kann entweder ein Windows-Konto für die SwyxWare Dienste automatisch erzeugen, oder man kann ein existierendes angeben. Das automatisch erzeugte Konto hat KEINE Windows-Adminrechte, und darf sie auch nicht haben.
   Es gab mehrfach Fälle, bei denen der Kunde einen Windows-Account speziell zur Administration der SwyxWare angelegt hatte, mit dem sich der Dienstleister anmelden konnte. Dieser Account hatte volle Adminrechte auf dem lokalen Server. Das ist auch völlig problemlos. Aus Gründen der Einfachheit wurde bei der Konfiguration der SwyxWare dieses Konto allerdings auch als Dienstekonto hinterlegt.
   Ergebnis: Die SwyxWare-Dienste laufen jetzt mit lokalen Administrator-Rechten, oder - falls man ein Konto mit Domänen-Adminrechnen nimmt - gleich mit administrativen Rechten für die ganze Domäne.
   Das bedeutet: Auch jedes Script in einem Callrouting läuft in diesem Fall mit Adminrechten, und da man als SwyxWare-User auch VBScript-Blöcke schreiben kann, haben auch DIESE jetzt Adminrechte auf dem lokalen Server oder gleich auf der Domäne. Das ermöglicht es Benutzern mit genügen tiefen Kenntnisse, über Callrouting-Scripte auf einzelne Rechner oder gleich auf die Domäne zuzugreifen! Die SwyxWare-Dienste sollten also niemals mit Adminrechten laufen.