ACL: auth_calls + apply-inbound-acl/auth-acl
Hi all, I'm trying to understand FreeSWITCH's ACL concepts, but I find the documentation not clear with respect to a combined effect of various *acl* params with auth-calls. Could you please provide your comments on the following? The documentation (https://freeswitch.org/confluence/display/FREESWITCH/ACL) says: /auth-calls: Can be set to true/false forcing users to authenticate or no on the profile. Only allow users from a specific cidr to register/make calls.// / First of all, it's not clear what's the default value of the auth-calls param. If it's not explicitly defined, is it true or false? (BTW, same happens with a lot of other params, i.e. no default value specified in the docs, and for some params I couldn't even find the default values in the sources.) Then, if auth-calls is set to true, will it ignore all *acl* params and always force auth? Or will it force auth only for those not specified in the *acl* params (e.g. IPs in apply-inbound-acl won't be forced to auth, all others will be). Similar doubt with the false value: will it always ignore auth or will it ignore auth for the IPs in the *acl* params and still require it for everything else? Then the documentation specifies: /apply-inbound-acl: Allow users to make calls from a particular cidr without authenticating. Phones having IPs within these ACLs will be able to perform calls (apply-inbound-acl) or register (apply-register-acl) without having to provide a password (i.e. without getting a "401 Unauthorized" challenge message).// / So if I understand it correctly, if I want a particular host (e.g. my SIP trunk provider) to make inbound calls without auth, but everyone else to be rejected with Unauthorized, I should specify in the corresponding sip profile: <param name="apply-inbound-acl" value="1.2.3.4/32"/> The documentation adds: /The ACL behavior is modified by auth-calls, accept-blind-reg, and accept-blind-auth./ So what should be the value for auth-calls in this case? How would it modify the behavior of apply-inbound-acl (i.e. apply-inbound-acl + auth-calls=false and apply-inbound-acl + auth-calls=true)? Then, the documentation says: /auth-calls: Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. Note: this will require "auth-calls" to be set to true in your sip (sofia) profile.// / So, if I want to restrict my internal users to be able to register (providing their passwords) only from a specific range and be rejected with Unauthorized for other IPs or if not providing auth, should I configure the profile this way? <param name="auth-calls" value="true"/> <param name="auth-acl" value="1.2.3.0/24"/> My doubt here is: would auth-acl add an additional level of restriction without altering the default behavior of auth-calls (that is to request auth from everyone) or would it somehow relax the default behavior for some cases? Thanks, Anatoli
Could someone please shed light on this topic? *From:* Anatoli *Sent:* Wednesday, November 08, 2017 18:12 *To:* Freeswitch-users *Subject:* [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl Hi all, I'm trying to understand FreeSWITCH's ACL concepts, but I find the documentation not clear with respect to a combined effect of various *acl* params with auth-calls. Could you please provide your comments on the following? The documentation (https://freeswitch.org/confluence/display/FREESWITCH/ACL) says: /auth-calls: Can be set to true/false forcing users to authenticate or no on the profile. Only allow users from a specific cidr to register/make calls.// / First of all, it's not clear what's the default value of the auth-calls param. If it's not explicitly defined, is it true or false? (BTW, same happens with a lot of other params, i.e. no default value specified in the docs, and for some params I couldn't even find the default values in the sources.) Then, if auth-calls is set to true, will it ignore all *acl* params and always force auth? Or will it force auth only for those not specified in the *acl* params (e.g. IPs in apply-inbound-acl won't be forced to auth, all others will be). Similar doubt with the false value: will it always ignore auth or will it ignore auth for the IPs in the *acl* params and still require it for everything else? Then the documentation specifies: /apply-inbound-acl: Allow users to make calls from a particular cidr without authenticating. Phones having IPs within these ACLs will be able to perform calls (apply-inbound-acl) or register (apply-register-acl) without having to provide a password (i.e. without getting a "401 Unauthorized" challenge message).// / So if I understand it correctly, if I want a particular host (e.g. my SIP trunk provider) to make inbound calls without auth, but everyone else to be rejected with Unauthorized, I should specify in the corresponding sip profile: <param name="apply-inbound-acl" value="1.2.3.4/32"/> The documentation adds: /The ACL behavior is modified by auth-calls, accept-blind-reg, and accept-blind-auth./ So what should be the value for auth-calls in this case? How would it modify the behavior of apply-inbound-acl (i.e. apply-inbound-acl + auth-calls=false and apply-inbound-acl + auth-calls=true)? Then, the documentation says: /auth-calls: Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. Note: this will require "auth-calls" to be set to true in your sip (sofia) profile.// / So, if I want to restrict my internal users to be able to register (providing their passwords) only from a specific range and be rejected with Unauthorized for other IPs or if not providing auth, should I configure the profile this way? <param name="auth-calls" value="true"/> <param name="auth-acl" value="1.2.3.0/24"/> My doubt here is: would auth-acl add an additional level of restriction without altering the default behavior of auth-calls (that is to request auth from everyone) or would it somehow relax the default behavior for some cases? Thanks, Anatoli _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi, Your mail is dense, I will try to answer at my best from my understanding of the source code: - the default value for auth-call is false. - When a call arrives, the apply-inbound-acl is checked first: * If the IP is approved by the acl, the access is granted * If the IP is rejected by the acl and auth-call is false, sofia responds with 403 forbidden (I skip the proxy-acl and X-AUTH-IP checks for simplicity) * If the IP is rejected by the acl and auth-call is true, it falls back to digest auth. - If accept-blind-auth is set with auth-call, freeswitch only checks if the From user is defined in directory. If so, user is authorized (without any password check) - If auth-cal is set without the acl, the call go through digest authentication - If neither is set, the call is accepted. In your case, even if you can define directly a cidr in the apply-inbound-acl param value, it would be best to set it to a list name defined in autoload_configs/acl.conf.xml. Hope this helps! -- Best Regards, Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 21 Nov 2017, at 05:26, Anatoli <me@anatoli.ws> wrote:
Could someone please shed light on this topic?
From: Anatoli Sent: Wednesday, November 08, 2017 18:12 To: Freeswitch-users Subject: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl
Hi all,
I'm trying to understand FreeSWITCH's ACL concepts, but I find the documentation not clear with respect to a combined effect of various *acl* params with auth-calls. Could you please provide your comments on the following?
The documentation (https://freeswitch.org/confluence/display/FREESWITCH/ACL) says:
auth-calls: Can be set to true/false forcing users to authenticate or no on the profile. Only allow users from a specific cidr to register/make calls.
First of all, it's not clear what's the default value of the auth-calls param. If it's not explicitly defined, is it true or false? (BTW, same happens with a lot of other params, i.e. no default value specified in the docs, and for some params I couldn't even find the default values in the sources.)
Then, if auth-calls is set to true, will it ignore all *acl* params and always force auth? Or will it force auth only for those not specified in the *acl* params (e.g. IPs in apply-inbound-acl won't be forced to auth, all others will be). Similar doubt with the false value: will it always ignore auth or will it ignore auth for the IPs in the *acl* params and still require it for everything else?
Then the documentation specifies:
apply-inbound-acl: Allow users to make calls from a particular cidr without authenticating. Phones having IPs within these ACLs will be able to perform calls (apply-inbound-acl) or register (apply-register-acl) without having to provide a password (i.e. without getting a "401 Unauthorized" challenge message).
So if I understand it correctly, if I want a particular host (e.g. my SIP trunk provider) to make inbound calls without auth, but everyone else to be rejected with Unauthorized, I should specify in the corresponding sip profile:
<param name="apply-inbound-acl" value="1.2.3.4/32"/>
The documentation adds: The ACL behavior is modified by auth-calls, accept-blind-reg, and accept-blind-auth.
So what should be the value for auth-calls in this case? How would it modify the behavior of apply-inbound-acl (i.e. apply-inbound-acl + auth-calls=false and apply-inbound-acl + auth-calls=true)?
Then, the documentation says:
auth-calls: Users in the directory can have "auth-acl" parameters applied to them so as to restrict users access to a predefined ACL or a CIDR. Note: this will require "auth-calls" to be set to true in your sip (sofia) profile.
So, if I want to restrict my internal users to be able to register (providing their passwords) only from a specific range and be rejected with Unauthorized for other IPs or if not providing auth, should I configure the profile this way?
<param name="auth-calls" value="true"/> <param name="auth-acl" value="1.2.3.0/24"/>
My doubt here is: would auth-acl add an additional level of restriction without altering the default behavior of auth-calls (that is to request auth from everyone) or would it somehow relax the default behavior for some cases?
Thanks, Anatoli
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Vallimamod, Thanks a lot for your detailed explanation, sure it helps! It would be great to add these details to the documentation (not sure whom to ask about this). IMO the behavior you describe can't be inferred from the current documentation and it deals with security/authentication. Could you please explain what would be the effect of auth-calls=true + auth-acl=<ip_range>? I suppose if the IP matches, it goes through the digest auth. If the IP doesn't match, sofia responds with 403 forbidden, right? Thanks, Anatoli *From:* Vallimamod Abdullah *Sent:* Tuesday, November 21, 2017 09:35 *To:* Freeswitch Users Help *Subject:* Re: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl Hi, Your mail is dense, I will try to answer at my best from my understanding of the source code: - the default value for auth-call is false. - When a call arrives, the apply-inbound-acl is checked first: * If the IP is approved by the acl, the access is granted * If the IP is rejected by the acl and auth-call is false, sofia responds with 403 forbidden (I skip the proxy-acl and X-AUTH-IP checks for simplicity) * If the IP is rejected by the acl and auth-call is true, it falls back to digest auth. - If accept-blind-auth is set with auth-call, freeswitch only checks if the From user is defined in directory. If so, user is authorized (without any password check) - If auth-cal is set without the acl, the call go through digest authentication - If neither is set, the call is accepted. In your case, even if you can define directly a cidr in the apply-inbound-acl param value, it would be best to set it to a list name defined in autoload_configs/acl.conf.xml. Hope this helps!
Hi Anatoli, Just saw your email. The auth-acl is always checked first. If it passes, the call is accepted with no further check. Only if it fails: - If auth-calls is true, digest auth is tried (that's why in logs you have: "Rejected by acl "xxx". Falling back to Digest auth.") - else, call is rejected. Hope this helps to make things clearer! Best Regards, -- Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 23 Nov 2017, at 22:48, Anatoli <me@anatoli.ws> wrote:
Hi Vallimamod,
Thanks a lot for your detailed explanation, sure it helps! It would be great to add these details to the documentation (not sure whom to ask about this). IMO the behavior you describe can't be inferred from the current documentation and it deals with security/authentication.
Could you please explain what would be the effect of auth-calls=true + auth-acl=<ip_range>? I suppose if the IP matches, it goes through the digest auth. If the IP doesn't match, sofia responds with 403 forbidden, right?
Thanks, Anatoli
From: Vallimamod Abdullah Sent: Tuesday, November 21, 2017 09:35 To: Freeswitch Users Help Subject: Re: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl
Hi,
Your mail is dense, I will try to answer at my best from my understanding of the source code:
- the default value for auth-call is false.
- When a call arrives, the apply-inbound-acl is checked first: * If the IP is approved by the acl, the access is granted * If the IP is rejected by the acl and auth-call is false, sofia responds with 403 forbidden (I skip the proxy-acl and X-AUTH-IP checks for simplicity) * If the IP is rejected by the acl and auth-call is true, it falls back to digest auth.
- If accept-blind-auth is set with auth-call, freeswitch only checks if the From user is defined in directory. If so, user is authorized (without any password check)
- If auth-cal is set without the acl, the call go through digest authentication
- If neither is set, the call is accepted.
In your case, even if you can define directly a cidr in the apply-inbound-acl param value, it would be best to set it to a list name defined in autoload_configs/acl.conf.xml.
Hope this helps!
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Vallimamod, Thanks a lot! My supposition was wrong. Quite non-trivial behavior again. Your explanation definitely should be added to the documentation. Regards, Anatoli *From:* Vallimamod Abdullah *Sent:* Wednesday, December 06, 2017 08:19 *To:* Freeswitch Users Help *Subject:* Re: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl Hi Anatoli, Just saw your email. The auth-acl is always checked first. If it passes, the call is accepted with no further check. Only if it fails: - If auth-calls is true, digest auth is tried (that's why in logs you have: "Rejected by acl "xxx". Falling back to Digest auth.") - else, call is rejected. Hope this helps to make things clearer! Best Regards, -- Vallimamod Abdullah SIP Solutions vma@sipsolutions.fr .
On 23 Nov 2017, at 22:48, Anatoli<me@anatoli.ws> wrote:
Hi Vallimamod,
Thanks a lot for your detailed explanation, sure it helps! It would be great to add these details to the documentation (not sure whom to ask about this). IMO the behavior you describe can't be inferred from the current documentation and it deals with security/authentication.
Could you please explain what would be the effect of auth-calls=true + auth-acl=<ip_range>? I suppose if the IP matches, it goes through the digest auth. If the IP doesn't match, sofia responds with 403 forbidden, right?
Thanks, Anatoli
From: Vallimamod Abdullah Sent: Tuesday, November 21, 2017 09:35 To: Freeswitch Users Help Subject: Re: [Freeswitch-users] ACL: auth_calls + apply-inbound-acl/auth-acl
Hi,
Your mail is dense, I will try to answer at my best from my understanding of the source code:
- the default value for auth-call is false.
- When a call arrives, the apply-inbound-acl is checked first: * If the IP is approved by the acl, the access is granted * If the IP is rejected by the acl and auth-call is false, sofia responds with 403 forbidden (I skip the proxy-acl and X-AUTH-IP checks for simplicity) * If the IP is rejected by the acl and auth-call is true, it falls back to digest auth.
- If accept-blind-auth is set with auth-call, freeswitch only checks if the From user is defined in directory. If so, user is authorized (without any password check)
- If auth-cal is set without the acl, the call go through digest authentication
- If neither is set, the call is accepted.
In your case, even if you can define directly a cidr in the apply-inbound-acl param value, it would be best to set it to a list name defined in autoload_configs/acl.conf.xml.
Hope this helps!
participants (2)
-
Anatoli
-
Vallimamod Abdullah