ACL in FreeSWITCH
In this article I will try to collect in one article extracts from the documentation and the information about the Acces Control List (ACL) in FreeSWITCH that is known to me.
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:
One or more named ACLs can be defined in network-lists:
The list must have a unique name, and the default attribute defines the default action, deny (forbid) or allow (allow).
Note that FreeSWITCH automatically creates several ACLs with the following names:
rfc1918.auto - RFC 1918
nat.auto - RFC 1918 excluding your local network
localnet.auto - ACL for your local network
loopback.auto - ACL for your local network
RFC 1918 defines the following IP address ranges for local area 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
The list defines one or more nodes - node:
<node type = "allow" cidr = "1.2.3.0/24" />
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 (<list default = “deny”>).
The attribute following the type can be one of the following:
cidr - specifies a range of IP addresses in the classless notation, for example: 192.168.0.0/16
domain - specifies the domain, can be specified as a variable, for example: $$ {domain}
host - specified, either a specific host, or with an additional parameter, mask, a range of hosts.
Examples:
So, acl.conf.xml simply gives the definitions of named ACLs, i.e. lists with allowed or not allowed ranges of IP addresses.
Where can they be used?
At least in three places: SIP profile, directory (directory) of subscribers and in event_socket.
Also ACL can be used in dialplan and API.
')
SIP profiles are usually located in conf / sip_profiles /
There are several ACL related parameters in the profile description.
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
The attributes can be: a named ACL (defined, for example, in autoload_configs \ acl.conf.xml) or CIDR:
Thus, if you have 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.
Firstly, this is not an error, this is a debugging (note: DEBUG) message, and secondly, it means that the ACL with the name “domains” is denied authorization and will be implemented via a password (Digest auth).
It is possible to prohibit such messages through the parameter <param name = "log-auth-failures" value = "false" />.
The parameters apply-inbound-acl and apply-register-acl can be defined several. In this case, all ACLs will be checked and the message will be rejected if any of the ACLs do not work (inside acl_list 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, this should be done using dialplan tools.
The parameter auth-calls is also closely related to the apply-inbound-acl and apply-register-acl parameters.
It determines whether the apply-inbound-acl and apply-register-acl check will be performed.
<param name = "auth-calls" value = "$$ {internal_auth_calls}" />
A value of false prevents 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 a proxy to add this header.
<param name = "apply-proxy-acl" value = "myproxies" />
Allows traffic to send FreeSWITCH through one or more proxy servers.
The proxy server should add a header called X-AUTH-IP containing the client's IP address.
FreeSWITCH trusts a proxy, because its IP is specified in the proxy 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 ACL:
accept-blind-auth - if set to true, then any authentication is accepted without checking
accept-blind-reg - if set to true, then any registration is accepted without verification
In the definition of the subscriber (user), you can specify CIDR:
You can also specify an ACL or CIDR in the auth-acl parameter when defining a user:
Thus, when auth-calls are enabled on the profile, the subscriber will be authorized not by the password, but by the specified ACL. Although, if the authorization by ACL fails, then it will still be authorized with a password.
To define access to the socket, you can add the apply-inbound-acl parameter, which specifies a named ACL or CIDR:
<param name = "apply-inbound-acl" value = "<acl_list | cidr>" />
Note that several apply-inbound-acl parameters will not work. It should be only one (compare with the SIP profile - there may be several, on the contrary).
The dialplan function check_acl allows you to check the ACL:
check_acl <ip> <acl | cidr> [<hangup_cause>]
For example:
This application may be caused by inline in diaplan.
reloadacl reloads ACLs:
acl checks IP address for ACL
Using the ACL, it can be routed by the acl application. For example, if you want to skip calls for hosts in the ACL list named list_foo:
Well, in general, something like that.
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:
<configuration name="acl.conf" description="Network Lists"> <network-lists> </network-lists> </configuration> One or more named ACLs can be defined in network-lists:
<list name="test" default="deny"> <node type="allow" cidr="1.2.3.0/24"/> </list> The list must have a unique name, and the default attribute defines the default action, deny (forbid) or allow (allow).
Note that FreeSWITCH automatically creates several ACLs with the following names:
rfc1918.auto - RFC 1918
nat.auto - RFC 1918 excluding your local network
localnet.auto - ACL for your local network
loopback.auto - ACL for your local network
RFC 1918 defines the following IP address ranges for local area 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
The list defines one or more nodes - node:
<node type = "allow" cidr = "1.2.3.0/24" />
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 (<list default = “deny”>).
The attribute following the type can be one of the following:
cidr - specifies a range of IP addresses in the classless notation, for example: 192.168.0.0/16
domain - specifies the domain, can be specified as a variable, for example: $$ {domain}
host - specified, either a specific host, or with an additional parameter, mask, a range of hosts.
Examples:
<node type="allow" domain="$${domain}"/> <node type="deny" cidr="192.168.42.0/24"/> <node type="deny" host="4.3.2.0" mask="255.255.255.0"/> So, acl.conf.xml simply gives the definitions of named ACLs, i.e. lists with allowed or not allowed ranges of IP addresses.
Where can they be used?
At least in three places: SIP profile, directory (directory) of subscribers and in event_socket.
Also ACL can be used in dialplan and API.
')
Sip profile
SIP profiles are usually located in conf / sip_profiles /
There are several ACL related parameters in the profile description.
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
The attributes can be: a named ACL (defined, for example, in autoload_configs \ acl.conf.xml) or CIDR:
<param name="apply-inbound-acl" value="<acl_list|cidr>"/> <param name="apply-register-acl" value="<acl_list|cidr>"/> Thus, if you have 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.
Firstly, this is not an error, this is a debugging (note: DEBUG) message, and secondly, it means that the ACL with the name “domains” is denied authorization and will be implemented via a password (Digest auth).
It is possible to prohibit such messages through the parameter <param name = "log-auth-failures" value = "false" />.
The parameters apply-inbound-acl and apply-register-acl can be defined several. In this case, all ACLs will be checked and the message will be rejected if any of the ACLs do not work (inside acl_list 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, this should be done using dialplan tools.
The parameter auth-calls is also closely related to the apply-inbound-acl and apply-register-acl parameters.
It determines whether the apply-inbound-acl and apply-register-acl check will be performed.
<param name = "auth-calls" value = "$$ {internal_auth_calls}" />
A value of false prevents 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 a proxy to add this header.
<param name = "apply-proxy-acl" value = "myproxies" />
Allows traffic to send FreeSWITCH through one or more proxy servers.
The proxy server should add a header called X-AUTH-IP containing the client's IP address.
FreeSWITCH trusts a proxy, because its IP is specified in the proxy 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 ACL:
accept-blind-auth - if set to true, then any authentication is accepted without checking
accept-blind-reg - if set to true, then any registration is accepted without verification
Directory (directory) of subscribers
In the definition of the subscriber (user), you can specify CIDR:
<user id="1000" cidr="12.34.56.78/32,20.0.0.0/8"> You can also specify an ACL or CIDR in the auth-acl parameter when defining a user:
<include> <user id="1000" number-alias="1000"> <params> <param name="password" value="1234"/> <param name="vm-password" value="1000"/> <param name="auth-acl" value="1.2.3.0/8"/> </params> <variables> <variable name="accountcode" value="1000"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value="Extension 1000"/> <variable name="effective_caller_id_number" value="1000"/> </variables> </user> </include> Thus, when auth-calls are enabled on the profile, the subscriber will be authorized not by the password, but by the specified ACL. Although, if the authorization by ACL fails, then it will still be authorized with a password.
event_socket
To define access to the socket, you can add the apply-inbound-acl parameter, which specifies a named ACL or CIDR:
<param name = "apply-inbound-acl" value = "<acl_list | cidr>" />
Note that several apply-inbound-acl parameters will not work. It should be only one (compare with the SIP profile - there may be several, on the contrary).
Applications (applicatons)
The dialplan function check_acl allows you to check the ACL:
check_acl <ip> <acl | cidr> [<hangup_cause>]
For example:
<action application="check_acl" data="${network_addr} foo normal_clearing"/> <action application="check_acl" data="${network_addr} 1.2.3.0/8 normal_clearing"/> This application may be caused by inline in diaplan.
API Commands
reloadacl reloads ACLs:
reloadacl [<reloadxml>] If you change acl.conf.xml, you can reload the existing list.acl checks IP address for ACL
acl <ip> <list|net> 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 the 'list_foo' link to the list name that you defined in acl.conf.xmlUsing the ACL, it can be routed by the acl application. For example, if you want to skip calls for hosts in the ACL list named list_foo:
<extension name="foo-hosts-calls"> <condition field="${acl(${network_addr} list_foo)}" expression="true"/> <condition field="destination_number" expression="(.*)"> <action application="bridge" data="sofia/default/$1@xxxx:5060"/> </condition> </extension> Well, in general, something like that.
Source: https://habr.com/ru/post/141727/
All Articles