This page contains several important settings of the system that affect the security of the system. You need to log in as admin in the Vodia PBX web interface. The settings are found under Settings → Security → General.

Administrator Login

It is critical that the system administrator login is protected from unauthorized access. We recommend that you choose a high-security password. The password is stored in a hashed format so it cannot be read from the global configuration file.

• Username: This is the administrator’s user name. By default, the user name is admin. This can be changed to anything (username change is recommended) however it cannot contain the @ character. Please note that the name is case sensitive.
• Password: This field sets the password for the user name indicated in the previous setting. By default, there is no password; however, it is obviously recommended that you set one.
• Allow login only from listed addresses: Limiting access to certain addresses can help reduce the risk of unauthorized access. This field accepts a list of IP addresses and IP addresses with a netmask that tell the PBX which addresses are allowed. If the field is empty, every address is allowed.

Security

• Web Session Timeout This field determines the length of time a web session will stay active before it times out. The duration is set in seconds, and the default value is 3600 seconds (1 hour). Increase or decrease this setting depending on whether you want the system to log you off after a certain period of time.
• TLS session duration: This setting defines how long the TLS session should be kept in the system. When the client and the server keep the session, setting up a new TLS connection is much faster than negotiating a new session from scratch.
• Keep track of login: The system keeps a log of administrator logins. This setting controls how long the history will be. The default is 14 days.
• Password strength: This field is used to specify the types of passwords that are acceptable. The default is "Accept All Passwords," but it is advisable to require medium or high-security passwords. Users should be encouraged to avoid passwords that are dictionary words and to instead create passwords that are more challenging. Medium security requires a score of 120 or higher, high security a score of 200 or higher. A combination of letters, digits, and symbols is recommended. The following table shows the points for characters in the password:

Character Type	Points
Digits	10
Upper/lowercase letters	26
Symbols	28

• Two factor authentication for login: This drop down determines what factors are used for the two-factor authentication. If there is no factor selected, the two factor authentication is turned off.
• Default tenant PIN size: If there is no PIN size set within the tenant, this setting will be used.
• TLS Minimum Version: This field defines the minimum allowed version for TLS. It affects all TLS connections except the UDP-based DTLS (see below), including HTTPS and SIPS.
• TLS Maximum Version: As with the minimum version, the system can also limit the maximum TLS version. This can make sense for compatibility reasons; however generally it makes sense to allow the highest available version.
• DTLS Minimum Version: As with the previous setting, this restricts what TLS version is used, however if affects DTLS which is used for RTP key negotiation.
• DTLS Maximum Version: As with the previous setting, this restricts what TLS version is used.
• TLS RC4: The RC4 cipher is today considered insecure. It is recommended that RC4 stays disabled. However older VoIP phones need this cipher in order to be able to use TLS.
• Allow empty passwords: By default every extension on the system must have a password. However some devices are not able to provide a password, then this setting needs to be turned on. Obviously it is strongly recommended to keep this setting turned off.
• Duration for app pairing barcodes: The barcodes for pairing the apps with the system contain a token that will expire after a certain time. This settings will determine the duration. A shorter duration is more secure, and a longer duration is more convenient. The expiry can be turned off, which means that the system will use the users password in a hashed format that will not expire. Changing the users password will break the pairing.
• Include extension password and PIN in user welcome email: The user's password and mailbox PIN can be generated and emailed to them in the welcome email. This is more convenient however it implies exposing this potentially critical information.
• API access list: The API access list settings control who can access the PBX API without a session as administrator. This is useful when using external servers to control the PBX settings. It contains a list, separated by space characters, that match the incoming request. The match is either done based on the IP address (e.g. 1.2.3.4, 192.168.0.0/16 or localhost) or the Basic authentication of the HTTP request. The basic authentication information is usually in the form "username:password", but can actually be anything that is sent in the "Basic" authentication header of the HTTP request. This makes it easier to access the server from locations with changing IP addresses. The settings was called "SOAP Trusted IP" in older versions.
• CSTA access list: Some CSTA clients are not able to log in to the PBX using the "StartApplicationSession" method. Those clients can be authenticated based on the IP address where they are coming from. The CSTA access list uses the format user@domain:adr. The username must be an existing account in the domain. The address must be a IPv4 or IPv6 address that the PBX perceives on an incoming call. The CSTA messages themselves need to contain the 8-byte header that includes the version number and the XML length, followed by the CSTA message in XML format.
• TLS key log file: When tracing packets with Wireshark or other PCAP-based tools, the PBX can write the master key into a key log file. In Wireshark, this file can be set in Preferences→Protocols→SSL→(Pre)-Master-Secret log filename.
• Ignore packets from those User-Agents: Network scanners are often using certain names in their User-Agent string. This setting tells the PBX which of those scanners should be ignored. Because the scanner will not receive any traffic back, it will likely give up on scanning. Although this does not avoid the problem of scanning in general, it helps to reduce the load on the system caused by scanners. The list is separated by space characters, starting with version 5.3.3 the system also accepts quoted user agents like "SIP Call", so that the user agent string may contain spaces.
• Ignore packets that do not match a domain on the system: When scanning the network, scanners must not only guess the right IP address. In multi-tenant systems, they must also guess the right domain name. This setting helps to keep unauthorized traffic off the system. If this setting is turned on, requests that do not contain a local domain name are ignored, unless the name localhost is used on the system. Exceptions are when the IP address was white-listed or the IP address belongs to a trunk on the system (since version 5.3).

System Administrators


With the Vodia PBX moving more and more into the cloud, we needed to address an old problem. There are usually several persons taking care of the system. Giving them all the same username and password is a bad idea, just like giving everyone the master key for the building. As employees join and leave companies, they must have their own credentials for logging into the system. There are three levels for administrators:

• Super Administrator
• System administrator
• Domain administrator

The Super Administrator has full control over the PBX, including managing other administrators. When upgrading to 5.0.4, this account will stay the same.

The System Administrator is similar to the super administrator, but cannot create, change or delete the super administrator or other system administrator accounts. There can be many system administrators, each one of them with their own password. To create one, simply give it a name and password and press Save. To delete a system administrator, simply remove the name you want to delete from the "Name" field and press Save, while the "Name" field is empty.

A Tenant Administrator can access only the settings inside a tenant. Those administrators can be set up in the tenant properties by the system or super administrators, and each tenant can have multiple administrators. Tenant administrators don’t count against account licenses.

IP Access Control

It is important for the stability of the system to control who has access to the network ports. This is controlled in the Settings → Security → Access page. There are several reasons why a system administrator might want to define who has access to the system:

• Protection against denial of service attacks: If you are operating the system on publicly available addresses, there is always the risk that someone will try to interrupt the service. Although the system has several protections against such attacks, it might be easier to rule out such attacks from the beginning.
• Limiting the service to authorized addresses: You might also want to limit the service to specific IP addresses only. For example, while you might allow users to register their IP phones in the office, you might allow only selected users with their associated IP addresses to register their phones from home.

Status

The status tab shows what IP addresses are allowed and which are blocked. When the system automatically blocks an address, it does that either for the entire address or for a specific port on the address. When manually enabling or disabling addresses, this can be done in a netmask basis, e.g. to enable a whole subnet. Automatic enabling or disabling is done one SIP or on HTTP basis (which includes protocols like LDAP and CSTA). Comments are either entered manually or are automatically generated by the system. For automatic entries, the system will show the duration that remains for the entry.

The delete button can be used to manually delete entries, for example because a entry was disabled during a false alarm. To permanently add a record that was automatically generated, use the add button. This will bring up the dialog where the administrator can also add a comment and further modify the add request (see below). The reload button reloads the table.

In order to import bulk addresses, the CSV button can be used. The format must be Address;Netmark;status;comment, where the netmask is the number of relevant bits (e.g. 8 for 10.0.0.0) and the status must be either enabled or disabled. When clicking on the CSV button the text field will show the currently loaded entries that don't have an expiration. This is useful for copy/pasting the content to another file. The CSV import will not delete any records, it will only add or overwrite records.

Addresses

This tab will show what TCP connections were accepted by the system without authentication. This counter does not consider authentication attempts. This is critical information for keeping the system safe and may trigger the disabling of IP addresses (see below). TCP connections are counted with the value 1, TLS are counted with value 3 to reflect the extra efford for setting up the TLS connection.

Browsers tend to open multiple connections simultaneously. For example, when a browser opens 10 connections on HTTPS, the connection counter would increase by 30.

Add

In order to manually add an entry, the add form can be used. There are two forms, one for IPv4 and another one for IPv6. Just enter the IP address, the net mask, and the access type, and click Create.

Settings

The following settings affect the enabling and disabling of IP addresses after a packet (e.g. SIP or HTTP) has been received by the system:

• Number of tolerated attempts: How many attempts one needs to give to the user to login into the system.
• Time for counting attempts: Time (in seconds) between which the attempts should be accounted for.
• Blacklist duration: The duration of which one wants to blacklist the IP after a failed login attempt.

These settings control after how many connections the system will disable addresses:

• Connections per address without authentication: This is the number of TCP connections made without authentication yet before the packet itself was received. Web browsers typically open a number of requests to download content as fast as possible without having authenticated yet. Because of this the threshold should not be too low, as this would trigger a false alarm.
• Clear connection counter after: Clear the counter for the field mentioned above, after specific amount of time.

More information on how it works

When a packet reaches the system, the system checks the list of enabled and disabled addresses for a match. If the request is ignored, the system discards the packet without answering. When the system checks the list for matches, a match occurs if a "source address" matches a "check address" with the mask. More specific addresses are checked first, making it possible to define exceptions to the general rule. Also, the system checks IPv4 and IPv6 addresses separately. If there is a match, the system checks for the type. If the type is Allow, then the system accepts the packet. If the type is Block, then the system blocks that request. If there is no match in the list, then the request is accepted. If the list is empty, the access control is disabled. This is the default behavior after the installation of the product.

For UDP-based requests, this is relatively easy—the request is just not answered. But because the UDP port is open, there is no ICMP request sent to the origin, which means if someone wants to attack the system, it might be possible for the attacker to figure out that there is an open port. But since the system just discards these messages, the damage is limited.

For TCP ports, the situation is more complicated. In Linux, there is no way for an application to determine where a TCP connection is coming from until the connection is accepted. This is why the system first accepts the connection and then examines whether the connection was allowed or not. If the connection was not allowed, then it is turned down immediately. In Windows, there is a special system call that first checks where the connection is coming from. If the source is not enabled, then the system does not accept the connection. However, because the operating system has already answered the TCP connection request with an acknowledge, in Windows it will be obvious that an application is running on the ports.

The behavior is to a certain extent similar to a firewall. However, especially for TCP, a firewall will be able to keep the traffic completely out. Someone testing the system out will not get any response back for a TCP request if the source IP address is not listed.

Example

The following table shows a scenario in which all users in the LAN are given access, but access from the public Internet is not allowed, except for an employee working from home and a trunk that comes from a service provider with a small range of IP addresses.

Address	Netmask	Type	Description
127.0.0.1	255.255.255.255	Allow	This will ensure that you can always access the HTTP interface from the local computer.
192.168.0.0	255.255.0.0	Allow	This will ensure that everyone in the LAN can access the system.
213.1.2.3	255.255.255.255	Allow	This will give the remote worker access to the system. Repeat the same entry for other IP addresses.
12.23.34.45	255.255.255.248	Allow	This entry is intended for the IP addresses of the ITSP.
0.0.0.0	0.0.0.0	Block	This entry will disable all packets by default.