Security hints for the configuration of a SwyxWare system

The SwyxWare, as a VoIP telephone system connected to the Internet, is potentially capable of causing costs for the owner by making unwanted calls. This article aims to list some potential configuration errors with SwyxWare, and the consequences that can result. In addition you will find hints how to "harden" a SwyxWare installation against such accesses.

For every single point there are more or less detailed explanations to explain the technical background.

Security advice about SIP logins and SwyxWare users

1. Logging on to a SwyxWare user can be done either with Windows authentication or with username/password combinations. At least the passwords should not be easy to guess. Especially for SIP end devices (Mediapack, Dect systems, etc.) a very simple configuration is often used: Phone number 100, user name 100, SIP UserID 100, password 100. This is generally not a problem, unless someone gets access to the customer's network. In that case, he can very quickly test out valid combinations using a simple brute force attack, and then make calls through the system at the customer's expense.
2. Port 5060 should *never* be accessible directly from the Internet. There are a large number of botnets that constantly scan the Internet for phone systems that are reachable on port 5060. As soon as such a system is found, brute force attacks on this address are carried out in large numbers in order to find valid credentials. If then the mistake from point 1) has been made, bots will relatively quickly log on to SwyxWare as users and use it for potentially costly calls abroad.
3. Also port 5096 must *never* be reachable from outside! This is the *internal* call control port of the Push Notification Service (PNS). On this port, the PNS acts as a proxy that forwards SIP packets directly to the server service. Reaching this port from the public Internet thus has practically the same effect as opening port 5060.
4. In general, only the ports that are really needed should be accessible from the public Internet. If there are any uncertainties when planning the forwardings based on our port list, our service team will be happy to help.
5. If the feature "Auto Attendant" is installed during the installation of SwyxWare, the configuration wizard automatically creates a user "Operator" and stores the script for said attendant tasks there. The automatically created user "Operator" should NOT be used to logon a real user. The stored script offers the possibility to enter a destination number via DTMF to which one would like to be connected.
   If a real user is registered here, then usually also the calling right of the user "Operator" is changed from the preconfigured "Internal calls" to "No call restriction", so that the user can also call externally. If then the installed script remains active and can be called in the call routing, then a caller can be connected through to the public exchange again, which again causes costs for the operator.

Security advice regarding SIP trunks

1. The botnets mentioned above no longer just search for the target port 5060, but also scan entire port ranges. This means that even a link manager, which must be externally accessible on port 65002, will be "discovered" sooner or later. Apart from security problems this can lead to load problems, depending on the capacity of the internet connection and the equipment of the SwyxWare machine. So it is recommended to allow incoming SIP packets in the firewall only from IP addresses which belong to the proxies of the corresponding SIP provider.
2. With many providers, it is necessary to configure SIP URIs in the trunk configuration in addition to the phone numbers. In the simplest case these are in the form <+49[area code][head number]*@*>. If you have several completely different phone numbers, however, you have to create a completely separate URI for each number, which of course means more work. We have seen several cases where a URI with the content <*@*> was created for the sake of simplicity. As a result, the link manager now accepts ANY incoming INVITE packet, regardless of whether the destination number is in its own number range or not!
   There are botnets that do not attempt registrations, but simply send INVITE packets on the off chance. With such a "catch all URI" the link manager accepts such INVITEs, which in the "best" case causes additional load on the system, because each of these packets is completely processed like a normal incoming call, until the server discards the call as undeliverable.
3. Calling rights are set not only for users, but also for trunk groups. For trunk groups, the default setting is "Internal calls". Unfortunately this is often misunderstood: This setting does NOT mean that calls cannot be made externally via this trunk. It rather means that the trunks in this trunk group are only allowed to *deliver* calls internally. If you set "No call restriction" on a trunk group, incoming calls on trunks in this trunk group inherit the right to be delivered to everywhere, also to external destinations! Such a configuration is only necessary if you want to route directly between trunks without delivering the calls to users. An example could be the operation of a sub-trunk. In such a case, however, precisely defined routing rules must be used to prevent incoming calls on other trunks from being sent back to the provider.
4. The maximum damage is caused by a combination of the errors from points 2 and 3. The following is a step-by-step description of what happens in this case:
   - An INVITE arrives at the link manager and contains (example) as destination "+15556832@nowhere.com".
   - The link manager accepts the INVITE thanks to the catch-all URI <*@*>.
   - The link manager passes the call to the server service for processing
   - The server service does not know the number, so it looks for a valid route to forward the call
   - All trunk groups leading to external have the forwarding entry for "+*" as usual
   - Because the call arrived with the right "No call restriction" it is forwarded to external.
   Result: SwyxWare is used as an open SIP relay to make international calls at the expense of the system operator without any form of registration.

General security information about SwyxWare

1. The configuration wizard can either automatically create a Windows account for the SwyxWare services, or you can specify an existing one. The automatically created account has NO Windows admin rights, and must not have them.
   There have been several cases where the customer had created a Windows account specifically for SwyxWare administration, with which the service provider could log in. This account had full admin rights on the local server. This is also completely unproblematic. For reasons of simplicity, however, this account was also stored as a service account when configuring SwyxWare.
   Result: The SwyxWare services now run with local administrator rights, or - if you take an account with domain admin rights - immediately with administrative rights for the whole domain.
   This means: Every script in callrouting are executed with admin rights now, and because custom VBScript blocks can be entered by SwyxWare users in their personal call routings, also THESE now have admin rights on the local server or even on the domain. This allows users with enough knowledge to access single machines or even the domain structure via callrouting scripts! So SwyxWare services should never run with administrative rights!