- Login as admin in the Vodia PBX web interface.
- Expand the menu Security under "Settings".
- From the expanded Security menu, click on General.
It is critical that the system administrator login be protected. 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).
- Password: This field sets the password for the user name indicated in the previous setting.By default, there is no password; however, it is recommended that you set one.
- Web Session Timeout (s): 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 (1 hour). Increase or decrease this setting depending on whether you want the system to log you off after a certain period of time. Once timed out, the main login screen will be displayed.
- 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. A combination of letters, digits, and symbols is recommended.
- 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.
- Accept all Passwords: All passwords will be accepted.
- Medium Security: The score must be 120 or higher.
- High Security: The score must be 200 or higher.
Character Type Points Digits 10 Upper/lowercase letters 26 Symbols 28
- API access list: The API access list settings controls 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, seperated by space characters, that match the incoming request. The match is either done based on the IP address (e.g.
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 adress 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.
- Ignore packets from those User-Agents: Network scanners are often using certain names in their User-Agent string. This settings tell 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 seperated 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 settings helps to keep unauthorized traffic of the system. If this setting it 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).
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 . 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.
The Domain Administrator is similar to what was previously known as domain administrator permission of an extension. Those domain administrators can be set up in the domain properties by the system or super administrators, and each domain can have multiple domain administrators.
Domain administrators don’t count against and account licenses. This was a problem with the previous concept, as usually one account had to be sacrificed for administration purposes. Also, the system administrators don’t count against the license.
This also explains why the "login as" selection box has disappeared from the login screen. Now it is well defined what role each account has.
- Expand the menu Security under "Settings".
- From the expanded Security menu, click on Access.
Automatically block the IP address that is attacking the system. You can also add IP addresses to the Access page and place a Block on them so that they will be unable to access the system. Just enter the IP address, the net mask, and the access type, and click Create. Enter only as much information as needed by the net mask; for example, if the net mask is "255.255.0.0" enter 192.168.0.0 To delete an entry, click the button.
Changing the entry does not require a restart of the system. The changes take effect immediately. You may specify IP addresses with their netmask and their policy. If there is no match, packets will be accepted. 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.
The motivation for the list is to provide the firewall type of functionality within the system application and reduce the chance of unauthorized access to the system. The access control is not only limited to SIP, but it also applies to all other protocols on the system, including HTTP, TFTP, and SNMP. When the system acts as a client (for example, when performing DNS requests), the rules do not apply. Using 0.0.0.0 in the IP field specifies that everything will be accepted. In addition, if you are getting a lot of requests from a particular source, the system will automatically add them to the access control list and block them.
How the Access List Functions
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.
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 two employees working from home and a trunk that comes from a service provider with a small range of IP addresses.
|Address||Net Mask||Type||Description of Result|
|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.|
|0.0.0.0||0.0.0.0||Block||This entry will disable all packets by default (enter this last; otherwise, you will be unable to access the system).|
|18.104.22.168||255.255.255.255||Allow||This will give the remote worker access to the system. Repeat the same entry for other IP addresses.|
|22.214.171.124||255.255.255.248||Allow||This entry is intended for the IP addresses of the ITSP.|