HOWTO Configure ACL Rules to Protect SIP Extensions from SIP Attacks

Ankica Omercausevic

Modified on: Mon, 2 Dec, 2024 at 2:21 AM

Purpose of ACL Rules for SIP extensions

SIP extensions are frequent targets for hackers, who exploit weak or stolen passwords to initiate unauthorized calls or disrupt services. Configuring Access Control Lists (ACLs) in PBXware ensures that only trusted IP addresses can register SIP extensions, providing an additional layer of security.

Note: This guide applies to SIP extensions that use secret passwords. It does not apply to gloCOM application, as gloCOM uses 'user password' for authentication, which follows a different security mechanism.

How ACLs Protect SIP Extensions

ACL rules allow you to:

Block all unauthorized IPs by default ensuring that no authorized sources can register to extension
Whitelist trusted IP addresses to permit registrations only from known devices or networks.

Steps to Configure ACL Rules for SIP Extensions

Log into PBXware system and navigate to the extension for which you want to create ACL rule.

Scroll down to the 'Additional Config' and click on Advanced

Enter your rules, for example:

[endpoint]
deny=0.0.0.0/0.0.0.0
permit=1.1.1.1

Click on Save.

Detailed ACL Configuration examples

1. Deny all Unauthorized IPs

Start by blocking all traffic by default with the following rule:

[endpoint]
deny=0.0.0.0/0.0.0.0

This rule ensures that no IP can register a SIP extension unless explicitly permitted.

2. Whitelist trusted IP addresses

Add rules to allow access only for trusted IP addresses or subnets where SIP devices are located. For example:

[endpoint]
deny=0.0.0.0/0.0.0.0
permit=192.168.1.100
permit=203.0.113.50
permit=192.168.0.0/24

These rules ensure that only devices from these IPs or subnets can register.

Important note on rule order:

PBXware processes ACL rules from top to bottom, and the first matching rule determines access.

Place the deny=0.0.0.0/0.0.0.0 rule first to block all access by default.
Add specific permit rules afterward to whitelist trusted IPs.

For example, this is correct:

[endpoint]
deny=0.0.0.0/0.0.0.0
permit=10.10.10.10

If the deny rule comes after the permit rule, the deny will override all other rules, blocking access entirely.