<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2172/18/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs+-+Creation+and+Usage">Named ACLs - Creation and Usage</a></h2>
<h4>Page <b>added</b> by <a href="https://wiki.asterisk.org/wiki/display/~jrose">Jonathan Rose</a>
</h4>
<br/>
<div class="notificationGreySide">
<div>
<ul>
<li><a href='#NamedACLs-CreationandUsage-Overview'>Overview</a></li>
<li><a href='#NamedACLs-CreationandUsage-DefiningNamedACLs'>Defining Named ACLs</a></li>
<li><a href='#NamedACLs-CreationandUsage-MakingconsumersuseNamedACLs'>Making consumers use Named ACLs</a></li>
<li><a href='#NamedACLs-CreationandUsage-ACLreloads'>ACL reloads</a></li>
<li><a href='#NamedACLs-CreationandUsage-RealtimeNamedACLs'>Realtime Named ACLs</a></li>
</ul></div>
<h2><a name="NamedACLs-CreationandUsage-Overview"></a>Overview</h2>
<p>Asterisk 11 introduces a new streamlined way for defining Access Control Lists (ACLs) to be shared among multiple consumers. Previously, ACLs had to be defined on a peer via some combination of permit and deny options which would compile together to create a complete ACL. This made defining ACLs for many users somewhat tedious with similar sets of rules and the method doesn't work well with Realtime consumers. To address these problems, we've added a means of creating ACL profiles which can be shared for multiple purposes by name.</p>
<h2><a name="NamedACLs-CreationandUsage-DefiningNamedACLs"></a>Defining Named ACLs</h2>
<p>Named ACLs can be defined in either the local named ACL configuration or in a database access via Asterisk's realtime configuration adapters (<a href="#NamedACLs-CreationandUsage-realtimeacls">more below</a>). In order to use them at all, an ACL configuration must be included in your defined astetcdir. Like all configurations for Asterisk, an example is included with the source in the configs directory which will be installed automatically when executing 'make samples'. Configuring named ACLs is relatively simple ans works more or less the same way as configuring ACLs by a consumer does. Some examples:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>; within acl.conf
[name_of_acl1]
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1
</pre>
</div></div>
<p>multiple rules can be specified in an ACL just as before.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>[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
</pre>
</div></div>
<p>Named ACLs support common modifiers like templates and additions within configuration as well.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>[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
</pre>
</div></div>
<p>With ACL rules defined, we can then use those with our ACL consumers.</p>
<h2><a name="NamedACLs-CreationandUsage-MakingconsumersuseNamedACLs"></a>Making consumers use Named ACLs</h2>
<p>The named ACL system is currently usable by Manager as well as current core level supported channel drivers which use ACLs (chan_sip and chan_iax2). Any configuration involving the permit/deny options is now joined by an acl option which can be used to add named ACLs to their access rules. For example:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>; 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
</pre>
</div></div>
<p>Any individual consumer of an ACL that uses the new functionality has an internal list of ACLs. Any number of ACLs can be placed within the list (barring duplicates of the same named ACL) and the rules set via permit/deny also comprise a separate ACL within the list (known as the base ACL). In the case of a list of ACLs with multiple individual rule sets (multiple named ACLs or named ACLs with a base ACL) being applied against an address, all of the ACLs are evaluated independently of the other rulesets and each ACL in the combined ruleset must allow the address individually in order for the combined list of ACLs to allow the address. To put it more concisely:</p>
<p>If a SIP peer has permit/deny rules and two named ACLs and a request to use that peer comes from an address which requires evaluation against that peer's ACL list and any one or more of those ACLs would have individually rejected the address, the address will be rejected outright just the same as if none of the ACLs had passed. Every ACL must be satisfied.</p>
<p>Like with permit/deny, multiple uses of acl can be used to specify multiple named ACLs. in addition to including multiple named ACLs that way though, you can simply separate individual named ACLs with commas. This makes named ACLs more viable use with realtime consumers of ACLs since a typical database table will only include one column for permit, one column for deny, and one column for acl options. Since only one option can be specified per permit/deny column (at the time of writing this document anyway), there isn't really a reliable or particularly useful way of creating ACLs for realtime peers without the use of named ACLs. Example:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>;this
acl=named_acl_1
acl=named_acl_2
...
;is the same as:
acl=named_acl_1,named_acl_2
</pre>
</div></div>
<h2><a name="NamedACLs-CreationandUsage-ACLreloads"></a>ACL reloads</h2>
<p>ACLs are basically static once defined. Changing ACLs in the middle of a dialog could result in bad dialogs, hung calls, and other nasty stuff, so for the time being at least, when we want to change the ACLs that have been defined, we have to perform reloads across each of the consumers. Since we didn't want users to have to individually touch configuration files and perform reloads against each module just because they want to change ACL.conf, we issue events upon reloading the named ACL subsystem which causes cascading reloads on any consumers that are currently using named ACLs. Don't reload the ACL system if you don't want any consumers that are currently using it to perform reloads as well.</p>
<p>Keep in mind that reloading many consumers will not result in the ACLs being applied immediately to any existing dialogs involving them. As such, don't treat the named ACL system like a dynamic means of blocking addresses. It's more of a tool for convenience and organization. It also makes diagnostics a little easier since it can isolate individual ACLs which were failed against for the purpose of applying an ACL. Asterisk is not a firewall and this isn't meant to provide the behavior of one.</p>
<p>In order to reload the ACL subsystem, simply issue the CLI command: reload acl<br/>
If the acl.conf configuration has changed, the reload will be performed at this point and all consumers currently relying on it will also perform reloads.</p>
<p><a name="NamedACLs-CreationandUsage-realtimeacls"></a></p>
<h2><a name="NamedACLs-CreationandUsage-RealtimeNamedACLs"></a>Realtime Named ACLs</h2>
<p>First, the extconfig name for ACLs is 'acls'. An example configuration would be the following:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>;in extconfig.conf
acls => odbc,asterisk,acltable
</pre>
</div></div>
<p>'odbc' specifies the adapter. 'asterisk' is the profile the adapter uses in res_odbc.conf (since its using the odbc adapter) and 'acltable' is the name of the table on the database used to store the named ACLs.</p>
<p>A typical named ACL database table contains the following columns:<br/>
name - up to 80 characters, name of the ACL (mandatory)<br/>
rule_order - integer. order that the rule appears in the ACL. Remember that the order of your permits/denies matters. It doesn't have to be numerically sequential (you can skip over numbers and all the rules will still be included in ascending order). (mandatory)<br/>
sense - characters. Either permit or deny. (mandatory)<br/>
rule - characters. the IP address/mask - the right side of the '=' in your typical permit/deny rule (mandatory)<br/>
systemname - characters. If the general acl.conf option 'systemname' is specified, only realtime ACLs with a matching systemname will be evaluated (optional)</p>
<p>Example creation Script for pgsql:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>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,
systemname charactervarying(80),
CONSTRAINT aclrulekey PRIMARY KEY (name, "order", rule, sense)\
)
WITH (
OIDS=FALSE
);
ALTER TABLE acltable OWNER TO asterisk;
GRANT ALL ON TABLE acltable TO asterisk;
)
</pre>
</div></div>
<p>Example SQL statement made for SQLite3:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>BEGIN TRANSACTION;
CREATE TABLE acltable (systemname TEXT, rule TEXT, sense TEXT, rule_order NUMERIC, name TEXT);
COMMIT;
</pre>
</div></div>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>These are just scripts generated by pgadmin III and SQLite Database Browser. They might not necessarily apply for your own setup.</td></tr></table></div>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Since ACLs are grabbed by consumers at configuration, a realtime ACL won't automatically be up to date in statically defined consumers unless a reload is issued against the consumer. Realtime consumers (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.</td></tr></table></div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs+-+Creation+and+Usage">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs+-+Creation+and+Usage?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>