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 Delete 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.|