ACL in FreeSWITCH

In this article I will try to collect in one article extracts from the documentation and the information I know about the Acces Control List (ACL) in FreeSWITCH.

So, the ACL configuration is written in the autoload_configs \ acl.conf.xml file. The
configuration tag is named acl.conf and inside it is the network-lists list tag:

In network-lists, one or more named ACLs can be defined:

The list must have a unique name and the default attribute defines the default action - deny (deny) or allow (allow).
Please note that FreeSWITCH automatically creates several ACLs with the following names:
rfc1918.auto - RFC 1918
nat.auto - RFC 1918 except for your local network
localnet.auto - ACL for your local network
loopback.auto - ACL for your local network

RFC 1918 defines the following ranges of IP addresses for local networks:
10.0.0.0 - 10.255.255.255 - 10.0.0.0/8
172.16.0.0 - 172.31.255.255 - 172.16.0.0/12
192.168.0.0 - 192.168.255.255 - 192.168.0.0/16

Listed one or several nodes is defined - node:

The attribute type of the node can be deny (deny) or allow (allow), it defines the rule for this node. Rules apply from less specific to more specific. The rules defined in the node overlap the rule defined by default in the list ()
The attribute following the type can be one of the following:
cidr - indicates the range of IP addresses in classless notation, for example: 192.168.0.0/16
domain - indicates the domain, can be specified as a variable, for example: $$ {domain}
host - indicates, either a specific host, or with an additional parameter mask the range of hosts.
Examples:

So, acl.conf.xml just gives the definitions of named ACLs, i.e. lists with allowed or not allowed ranges of IP addresses.
Where can I use them?
At least in three places: SIP profile, subscriber directory, and event_socket.
ACLs can also be used in dialplan and API.

SIP profile

SIP profiles are usually located in conf / sip_profiles /
In the profile description there are several parameters related to ACLs.

apply-inbound-acl - Allow users to make calls from a specific ACL / CIDR
apply-register-acl - Allow users to register from a specific ACL / CIDR

Attributes can be: a named ACL (defined, for example, in autoload_configs \ acl.conf. xml) or CIDR:

Thus, if you get this kind of message in the log:
2012-04-05 15: 08: 46.348105 [DEBUG] sofia.c: 7567 IP 82.xxx Rejected by acl "domains". Falling back to Digest auth.
That, firstly, this is not an error, it is a debugging (note - DEBUG) message, and secondly, it says that authorization is rejected by the ACL with the name "domains" and will be done through a password (Digest auth).
Such messages can be prohibited through the parameter .

The apply-inbound-acl and apply-register-acl parameters can be defined more than one. In this case, all ACLs will be checked and the message will be rejected if any of the ACLs does not fit (inside acl_list it is tested as OR, with several parameters it is tested as AND).
Phones with IP addresses in these ACLs will be able to make calls (apply-inbound-acl) or register (apply-register-acl) without specifying a password (that is, without receiving the “401 Unauthorized” message).
Remember that ACLs do not block any traffic . If you want to protect your FreeSWITCH, you need to configure a firewall. Also, if you want to limit outgoing calls, you must do this using dialplan.
Also, the apply-inbound-acl and apply-register-acl parameters are closely related to the auth-calls parameter .
It determines whether the apply-inbound-acl and apply-register-acl checks will be performed.

False prohibits the use of ACLs on this profile.
Note: Currently auth-calls does not work with proxy registration. You will need to do this inside your xml_curl script directory or on your proxy.
Another parameter:
apply-proxy-acl - use the IP specified in the X-AUTH-IP header received from the proxy server to check the ACL.
Note: You must configure the proxy to add this header.

Allows traffic to send FreeSWITCH through one or more proxies.
The proxy server must add a header named X-AUTH-IP containing the IP address of the client.
FreeSWITCH trusts the proxy because its IP is specified in the proxy’s ACL and uses the IP value in the header as the IP client for ACL authentication.
And two more, in my opinion, scary, parameters affect the use of ACLs:
accept-blind-auth - if set to true, then any authentication is accepted without verification
accept-blind-reg - if set to true, then any registration is accepted without verification

Directory of subscribers

In the definition of the subscriber (user), you can specify the CIDR:

ACL or CIDR can also be specified in the auth-acl parameter when defining a user:

Thus, when you enable auth-calls on the profile, the subscriber will not be authorized by password, but by the specified ACL. Although, if authorization by ACL fails, it will still be authorized by password.

event_socket

To determine access to a socket, you can add the apply-inbound-acl parameter, which specifies a named ACL or CIDR:

Note that several apply-inbound-acl parameters will not work. It should be only one (compare with the SIP profile - there can be several of them on the contrary).

Applications (applicatons)

Dialplan function check_acl allows you to check the ACL:
check_acl []
For example:

This application can be called inline in a glider.

API Commands

reloadacl reloads ACLs:

reloadacl []

If you changed acl.conf.xml, you can reload the existing list.

acl checks the IP address for an ACL

acl 

freeswitch@mybox> acl 192.168.42.42 192.168.42.0/24
freeswitch@mybox> acl 192.168.42.42 list_foo

For the second line of 'list_foo', a reference to the name of the list that you defined in acl.conf.xml.
Using an ACL, routing can be done by an acl application. For example, if you want to skip calls for hosts from an ACL named list_foo:

Well, in general terms, something like this.