Asterisk Project : Named ACLs This page last changed on Aug 08, 2012 by mjordan. ## Overview Named ACLs introduce a new way to define Access Control Lists (ACLs) in Asterisk. Unlike traditional ACLs defined in specific module configuration files, Named ACLs can be shared across multiple modules. Named ACLs can also be accessed via the Asterisk Realtime Architecture (ARA), allowing for run-time updates of ACL information that can be retrieved by multiple consumers of ACL information. ## Configuration ### Static Configuration Named ACLs can be defined statically in acl.conf. Each context in acl.conf defines a specific Named ACL, where the name of the context is the name of the ACL. The syntax for each context follows the permit/deny nomenclature used in traditional ACLs defined in a consumer module's configuration file.
Option | Value | Description
--- | --- | ---
deny | IP address [/Mask] | An IP address to deny, with an optional subnet mask to apply
permit | IP address [/Mask] | An IP address to allow, with an optional subnet mask to apply
#### Examples
    ; within acl.conf

    [name_of_acl1]
    deny=0.0.0.0/0.0.0.0
    permit=127.0.0.1
Multiple rules can be specified in an ACL as well by chaining deny/permit specifiers.
    [name_of_acl2]
    deny=10.24.0.0/255.255.0.0
    deny=10.25.0.0/255.255.0.0
    permit=10.24.11.0/255.255.255.0
    permit=10.24.12.0/255.255.255.0
Named ACLs support common modifiers like templates and additions within configuration as well.
    [template_deny_all](!)
    deny=0.0.0.0/0.0.0.0

    [deny_all_whitelist_these](template_deny_all)
    permit=10.24.20.1
    permit=10.24.20.2
    permit=10.24.20.3
### ARA Configuration The ARA supports Named ACLs using the 'acls' keyword in extconfig.conf. Example Configuration
    ;in extconfig.conf
    acls => odbc,asterisk,acltable
#### Schema
Column Name | Type | Description
--- | --- | ---
name | varchar(80) | Name of the ACL
rule_order | integer | Order to apply the ACL rule. Rules are applied in ascending order. Rule numbers do not have to be sequential
sense | varchar(6) | Either 'permit' or 'deny'
rule | varchar(95) | The IP address/Mask pair to apply
#### Examples ##### Table Creation Script (PostgreSQL)
    CREATE TABLE acltable
    (
       "name" character varying(80) NOT NULL,
       rule_order integer NOT NULL,
       sense character varying(6) NOT NULL,
       "rule" character varying(95) NOT NULL,
       CONSTRAINT aclrulekey PRIMARY KEY (name, rule_order, rule, sense)
    )
    WITH (
       OIDS=FALSE
    );
    ALTER TABLE acltable OWNER TO asterisk;
    GRANT ALL ON TABLE acltable TO asterisk;
    )
##### Table Creation Script (SQLite3)
    BEGIN TRANSACTION;
    CREATE TABLE acltable (rule TEXT, sense TEXT, rule_order NUMERIC, name TEXT);
    COMMIT;
| These scripts were generated by pgadmin III and SQLite Database Browser. They might not necessarily apply for your own setup.
| Since ACLs are obtained by consumer modules when they are loaded, an ACL updated in an ARA backend will not be propagated automatically to consumers using static configuration. Consumer modules also using ARA for their configuration (such as SIP/IAX2 peers) will similarly be up to date if and only if they have built the peer in question since the changes to the realtime ACL have taken place.
## Named ACL Consumers Named ACLs are supported by the following Asterisk components: Manager (IPv4 and IPv6) chan_sip (IPv4 and IPv6) chan_iax2 (IPv4 only) ### Configuration A consumer of Named ACLs can be configured to use a named ACL using the acl option in their ACL access rules. This can be in addition to the ACL rules traditionally defined in those configuration files. Example 1: referencing a Named ACL
    ; within sip.conf

    [peer1]
    ;stuff
    ;deny=0.0.0.0/0.0.0.0
    ;permit=127.0.0.1
    acl=name_of_acl_1 ; an ACL included from acl.conf that matches peer1's commented out permits/denies
Multiple named ACLs can be referenced as well by specifying a comma delineated list of Named ACLs to apply. Example 2: multiple Named ACL references
    ; within sip.conf

    [peer1]
    ;stuff
    acl=named_acl_1,named_acl_2
Similarly, a SIP or IAX2 peer defined in ARA can include an 'acl' column and list the Named ACLs to apply in that column.
| NOTE Named ACLs can also be defined using multiple instances of the acl keyword. This is discouraged, however, as the order in which ACLs are applied can be less obvious then the comma delineated list format.
    acl=named_acl_1
    acl=named_acl_2
### ACL Rule Application Each module consumer of ACL information maintains, for each object that uses the information, a list of the defined ACL rule sets that apply to that object. When an address is evaluated for the particular object, the address is evaluated against each rule. For an address to pass the ACL rules, it must pass each ACL rule set that was defined for that object. Failure of any ACL rule set will result in a rejection of the address. ## Module Reloads ACL information is static once a consumer module references that information. Hence, changes in ACL information in an ARA backend will not automatically update consumers of that information. In order for consumers to receive updated ACL information, the Named ACL component must be reloaded. The Named ACL component supports module reloads, in the same way as other Asterisk components. When the Named ACL component is reloaded, it will issue a request to all consumers of Named ACLs. Those consumer modules will also be automatically reloaded.
| WARNING This implies that reloading the Named ACL component will force a reload of manager, chan_sip, etc. Only reload the Named ACL component if you want all consumers of that information to be reloaded as well.

Document generated by Confluence on Nov 02, 2012 17:42