Combine non-auth and auth calls on same profile security consideration.
Hello. There where separate sip profiles for registered accounts and anonymous inbound calls: internal and external. All calls and registrations on internal a authenticated and routed to "default" context. For external profile inbound calls are not authenticated and are routed to "public" context. In order for some one to call inbound (s)he have to use :5080 port, which is somehow inconvenient. So I decided to combine in one profile named "example" on port 5060. <profile name="internal_77.89.245.34"> <settings> <param name="context" value="public"/> <param name="auth-calls" value="false"/> <param name="auth-all-packets" value="false"/> <param name="inbound-reg-force-matching-username" value="true"/> <param name="force-register-domain" value="default"/> <param name="force-subscription-domain" value="default"/> <param name="force-register-db-domain" value="default"/> </settings> </profile> <domain name="$${domain}"> <variables> <variable name="inbound-reg-force-matching-username" value="true"/> <variable name="user_context" value="default"/> <groups> <group name="default"> <users> <X-PRE-PROCESS cmd="include" data="default/*.xml"/> </users> </group> </groups> </variables> </domain> Registration was working, calling to those registration was working, but some phones hit public context, some default context. I started to dig whats happening and found that D-Link phones always do authenticated calls when they a registered, while Stephen's phones does unauthenticated and go to public. Then I found a mention that registrations allow only to find the phone to call, while calls does not necessary authenticate. So I used Anthony's solution in public context on the end: <extension name="check_auth" continue="true"> <condition field="${sip_authorized}" expression="^true$" break="never"> <anti-action application="respond" data="407"/> </condition> </extension> Now when a registered phone hits public context and no other conditions are met, they are rejected and call authenticated hitting default context. Then in CDR I see two lines: one with rejected and one with success. This is not well, so found a hint and put: <anti-action application="set" data="process_cdr=false"/> And now is working somewhat correct except that calls to public numbers which does not require authentication does not get vars for the registered extension. My questions are: 1) Does this type of combination affect security? 2) How to impose all registered phones to make authenticated calls always? So they will not go first thru public context and then to default? -- Mimiko desu.
On Tue, Jan 3, 2017 at 3:40 AM, Mimiko <vbvbrj@gmail.com> wrote:
Hello.
There where separate sip profiles for registered accounts and anonymous inbound calls: internal and external. All calls and registrations on internal a authenticated and routed to "default" context. For external profile inbound calls are not authenticated and are routed to "public" context.
In order for some one to call inbound (s)he have to use :5080 port, which is somehow inconvenient. So I decided to combine in one profile named "example" on port 5060.
<profile name="internal_77.89.245.34"> <settings> <param name="context" value="public"/> <param name="auth-calls" value="false"/> <param name="auth-all-packets" value="false"/> <param name="inbound-reg-force-matching-username" value="true"/> <param name="force-register-domain" value="default"/> <param name="force-subscription-domain" value="default"/> <param name="force-register-db-domain" value="default"/> </settings> </profile> <domain name="$${domain}"> <variables> <variable name="inbound-reg-force-matching-username" value="true"/> <variable name="user_context" value="default"/> <groups> <group name="default"> <users> <X-PRE-PROCESS cmd="include" data="default/*.xml"/> </users> </group> </groups> </variables> </domain>
Registration was working, calling to those registration was working, but some phones hit public context, some default context. I started to dig whats happening and found that D-Link phones always do authenticated calls when they a registered, while Stephen's phones does unauthenticated and go to public.
Then I found a mention that registrations allow only to find the phone to call, while calls does not necessary authenticate. So I used Anthony's solution in public context on the end:
<extension name="check_auth" continue="true"> <condition field="${sip_authorized}" expression="^true$" break="never"> <anti-action application="respond" data="407"/> </condition> </extension>
Now when a registered phone hits public context and no other conditions are met, they are rejected and call authenticated hitting default context.
Then in CDR I see two lines: one with rejected and one with success. This is not well, so found a hint and put: <anti-action application="set" data="process_cdr=false"/>
And now is working somewhat correct except that calls to public numbers which does not require authentication does not get vars for the registered extension.
My questions are:
1) Does this type of combination affect security? 2) How to impose all registered phones to make authenticated calls always? So they will not go first thru public context and then to default?
Its a lot to go through for the vanity of not having to type 5080 once in a config box, but that's just my opinion ;) You can use the set_user app to make unauthenticated calls get the same data as authenticated calls would have on a specified exten.
-- Mimiko desu.
_________________________________________________________________________ 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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
On 04.01.2017 19:07, Anthony Minessale wrote:
My questions are:
1) Does this type of combination affect security? 2) How to impose all registered phones to make authenticated calls always? So they will not go first thru public context and then to default?
Its a lot to go through for the vanity of not having to type 5080 once in a config box, but that's just my opinion ;)
You can use the set_user app to make unauthenticated calls get the same data as authenticated calls would have on a specified exten.
Anthony thank you for suggestion. Taking this public dialplan: <context name="public"> <extension name="unloop"> <condition field="${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> </extension> <extension name="sip_nat_detected" continue="true"> <condition field="${sip_nat_detected}" expression="^true$"> <action application="set" inline="true" data="sip-force-contact=NDLB-connectile-dysfunction"/> </condition> <extension name="public_did"> <condition field="destination_number" expression="^([5-8]\d\d)$"> <action application="transfer" data="$1 XML default"/> </condition> </extension> </extension> <extension name="check_auth" continue="true"> <condition field="${sip_authorized}" expression="^true$" break="never"> <anti-action application="set" data="process_cdr=false"/> <anti-action application="respond" data="407"/> </condition> </extension> </context> Where to put the set_user app? If I'll put it before "check_auth" extension like: <action application="set_user" data="${caller_id_number}@${domain}"/> Then any one calling from internet could set theirs caller_id_number to internal's one and act on behalf of some registered user to fraud. Or may be first extension in public dialplan to put something which will check, based on caller_id_number, if there is a registered user and impose to make authenticate call, like: <extension name="check_user_registered"> <condition field="${sofia_contact(${caller_id_number})}" expression="^error/" break="on-false"> <anti-action application="set" data="process_cdr=false"/> <anti-action application="respond" data="407"/> </condition> </extension> PS: Yes, its not to big to add :5080, but take callers that want to call from mobile via internet using a sip uri. Even myself forgets to add port number at the end. :) -- Mimiko desu.
Wouldn't it be simpler to make :5060 the unauthenticated port and :5080 the authenticated? On Jan 5, 2017 7:58 AM, "Mimiko" <vbvbrj@gmail.com> wrote:
On 04.01.2017 19:07, Anthony Minessale wrote:
My questions are:
1) Does this type of combination affect security? 2) How to impose all registered phones to make authenticated calls always? So they will not go first thru public context and then to default?
Its a lot to go through for the vanity of not having to type 5080 once in a config box, but that's just my opinion ;)
You can use the set_user app to make unauthenticated calls get the same data as authenticated calls would have on a specified exten.
Anthony thank you for suggestion.
Taking this public dialplan:
<context name="public"> <extension name="unloop"> <condition field="${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> </extension> <extension name="sip_nat_detected" continue="true"> <condition field="${sip_nat_detected}" expression="^true$"> <action application="set" inline="true" data="sip-force-contact=NDLB-connectile-dysfunction"/> </condition> <extension name="public_did"> <condition field="destination_number" expression="^([5-8]\d\d)$"> <action application="transfer" data="$1 XML default"/> </condition> </extension> </extension> <extension name="check_auth" continue="true"> <condition field="${sip_authorized}" expression="^true$" break="never"> <anti-action application="set" data="process_cdr=false"/> <anti-action application="respond" data="407"/> </condition> </extension> </context>
Where to put the set_user app? If I'll put it before "check_auth" extension like:
<action application="set_user" data="${caller_id_number}@${domain}"/>
Then any one calling from internet could set theirs caller_id_number to internal's one and act on behalf of some registered user to fraud.
Or may be first extension in public dialplan to put something which will check, based on caller_id_number, if there is a registered user and impose to make authenticate call, like:
<extension name="check_user_registered"> <condition field="${sofia_contact(${caller_id_number})}" expression="^error/" break="on-false"> <anti-action application="set" data="process_cdr=false"/> <anti-action application="respond" data="407"/> </condition> </extension>
PS: Yes, its not to big to add :5080, but take callers that want to call from mobile via internet using a sip uri. Even myself forgets to add port number at the end. :)
-- Mimiko desu.
_________________________________________________________________________ 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
On 05.01.2017 15:19, Russell Treleaven wrote:
Wouldn't it be simpler to make :5060 the unauthenticated port and :5080 the authenticated?
Maybe. For now I have more registered users than anonymous calls from internet. So, when configuring some device I easily can forget about port. :) Any way, its more about my questions, than switching ports. I considered this option and is last resort. -- Mimiko desu.
participants (3)
-
Anthony Minessale
-
Mimiko
-
Russell Treleaven