summaryrefslogtreecommitdiff
path: root/configs/acl.conf.sample
diff options
context:
space:
mode:
authorJonathan Rose <jrose@digium.com>2012-07-11 18:33:36 +0000
committerJonathan Rose <jrose@digium.com>2012-07-11 18:33:36 +0000
commit10afdf3a2abd7e45d5c1841b29744de5b852d722 (patch)
treeefd6960cc2e8a9f2642d8ac950904ba6c51371e9 /configs/acl.conf.sample
parent6190ae4430f2bdfb02d2ce8f4941cd9b4e65f5a0 (diff)
Named ACLs: Introduces a system for creating and sharing ACLs
This patch adds Named ACL functionality to Asterisk. This allows system administrators to define an ACL and refer to it by a unique name. Configurable items can then refer to that name when specifying access control lists. It also includes updates to all core supported consumers of ACLs. That includes manager, chan_sip, and chan_iax2. This feature is based on the deluxepine-trunk by Olle E. Johansson and provides a subset of the Named ACL functionality implemented in that branch. For more information on this feature, see acl.conf and/or the Asterisk wiki. Review: https://reviewboard.asterisk.org/r/1978/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'configs/acl.conf.sample')
-rw-r--r--configs/acl.conf.sample86
1 files changed, 86 insertions, 0 deletions
diff --git a/configs/acl.conf.sample b/configs/acl.conf.sample
new file mode 100644
index 000000000..ca6906d4b
--- /dev/null
+++ b/configs/acl.conf.sample
@@ -0,0 +1,86 @@
+;
+; Named Access Control Lists (ACLs)
+;
+; A convenient way to share acl definitions
+;
+; This configuration file is read on startup
+;
+; CLI Commands
+; -----------------------------------------------------------
+; acl show Show all named ACLs configured
+; acl show <name> Show contents of a particular named ACL
+; reload acl Reload configuration file
+;
+;[general]
+;systemname=asterisksystem1 ; If a system name is specified, realtime
+; ; ACLs will only be retrieved if they have
+; ; a systemname field that matches this value.
+; ; If it's less blank, the field is ignored.
+;
+; Any configuration that uses ACLs which has been made to be able to use named
+; ACLs will specify a named ACL with the 'acl' option in its configuration in
+; a similar fashion to the usual 'permit' and 'deny' options. Example:
+; acl=my_named_acl
+;
+; Multiple named ACLs can be applied by either comma separating the arguments or
+; just by adding additional ACL lines. Example:
+; acl=my_named_acl
+; acl=my_named_acl2
+;
+; or
+;
+; acl=my_named_acl,my_named_acl2
+;
+; ACLs specified by name are evaluated independently from the ACL specified via
+; permit/deny. In order for an address to pass a given ACL, it must pass both
+; the ACL specified by permit/deny for a given item as well as any named ACLs
+; that were specified.
+;
+;[example_named_acl1]
+;deny=0.0.0.0/0.0.0.0
+;permit=209.16.236.0
+;permit=209.16.236.1
+;
+;[example_named_acl2]
+;permit=0.0.0.0/0.0.0.0
+;deny=10.24.20.171
+;deny=10.24.20.103
+;deny=209.16.236.1
+;
+; example_named_acl1 above shows an example of whitelisting. When whitelisting, the
+; named ACLs should follow a deny that blocks everything (like deny=0.0.0.0/0.0.0.0)
+; The following example explains how combining the ACLs works:
+; <in another configuration>
+; [example_item_with_acl]
+; acl=example_named_acl1
+; acl=example_named_acl2
+;
+; Suppose 209.16.236.0 tries to communicate and the ACL for that example is applied to it...
+; First, example_named_acl1 is evaluated. The address is allowed by that ACL.
+; Next, example_named_acl2 is evaluated. The address isn't blocked by example_named_acl2
+; either, so it passes.
+;
+; Suppose instead 209.16.236.1 tries to communicate and the same ACL is applied.
+; First, example_named_acl1 is evaluated and the address is allowed.
+; However, it is blocked by example_named_acl2, so the address is blocked from the combined
+; ACL.
+;
+; Similarly, the permits/denies in specific configurations that make up an ACL definition
+; are also treated as a separate ACL for evaluation. So if we change the example above to:
+; <in another configuration>
+; [example_item_with_acl]
+; acl=example_named_acl1
+; acl=example_named_acl2
+; deny=209.16.236.0
+;
+; Then 209.16.236.0 will be rejected by the non-named component of the combined ACL even
+; though it passes the two named components.
+;
+;
+; Named ACLs can use ipv6 addresses just like normal ACLs.
+;[ipv6_example_1]
+;deny = ::
+;permit = ::1/128
+;
+;[ipv6_example_2]
+;permit = fe80::21d:bad:fad:2323