I noticed a typo in my post that may easily confuse someone...
<user id="7105551212" cidr="127.0.0.0/8//">
should be:
<user id="7105551212" cidr="127.0.0.0/8">
-metik
Metik wrote:
> Bill,
>
> I think you would add this to the user profile in the directory. The
> "brian.xml" example (located in ${confdir}/directory/) provided with the
> default/sample configuration files demonstrates how to to do this by
> introducing a "cidr" attribute to the the "user" element.
>
> Example:
>
> <user id="7105551212" cidr="127.0.0.0/8//">
> <params>
> <param name="password" value="opensaysme"/>
> <param name="vm-password" value="14916"/>
> </params>
> <variables>
> <variable name="user_context" value="default"/>
> </variables>
> </user>
>
> "http://wiki.freeswitch.org/wiki/Acl"; contains some great info
> (including a relevant example).
>
> -metik
>
> Bill W. wrote:
>
>> Hey Metik,
>>
>> Thanks so much for your insights and your help. And yes, I was able to
>> append the X-AUTH-IP header with no problem. But that didn't solve the
>> issue. After some more research, it appears that the problem isn't with
>> auth-calls at all.
>>
>> I disabled all auth-call directives in every sip profile and the
>> registration through a proxy is still being rejected.
>>
>> I looked in sofia_reg.c and if auth_acl is defined, sofia_reg checks the
>> ip variable against the auth_acl cidr.
>>
>> if (auth_acl) {
>> if (!switch_check_network_list_ip(ip, auth_acl)) {
>> switch_log_printf(SWITCH_CHANNEL_LOG,
>> SWITCH_LOG_WARNING, "IP %s Rejected by user acl %s\n", ip, auth_acl);
>> ret = AUTH_FORBIDDEN;
>> goto end;
>> }
>>
>> So I guess the question is, is it possible to control what gets put into
>> the ip variable?
>>
>> Thanks,
>> Bill
>>
>>
>> Metik wrote:
>>
>>
>>> Honestly, several years ago I accomplished this by mod'ing SER (which
>>> became OpenSER which was then forked to OpenSIPS and Kamalio) and using
>>> one cluster of proxies for subscriber endpoints and another for
>>> infrastructure (so that I could keep RTP flows optimized yet support
>>> double NAT when required by an endpoint). Although the network looks
>>> different today.
>>>
>>> However, we were never quite happy about the lack of media failover
>>> (complicated NAT) and evaluated several commercial solutions until
>>> finding Covergence (which is now, for better or for worse since the jury
>>> is still out, owned by ACME Packet). At the time, they offered the best
>>> mix of security (their forte) yet scaled very well in comparison to
>>> their competitors that I had tested in our lab (ACME Packet, Kagoor,
>>> Netrake, NexTone, Kagoor, and Jasomi). In fact, they made a great
>>> decision, not unlike that of the FS developers, to implement a
>>> proven/stable SIP protocol stack. Nothing is perfect and that does not
>>> mean that we did not spend a considerable amount of time documenting
>>> bugs so that they could be addressed and it would work as it should
>>>
>>> We still use OpenSIPS for certain CSCF functionality (due to its speed
>>> and flexibility since it is not a B2BUA).
>>>
>>> Based on Mathieu's response (and he is definitely someone that would
>>> know), it looks like you should be able to easily append a X-AUTH-IP
>>> header (via OpenSIPS) containing the IP address of the endpoint and call
>>> it a day.
>>>
>>> -metik
>>>
>>>
>>> Bill W wrote:
>>>
>>>
>>>> Hey Metik,
>>>>
>>>> That's exactly what I'm trying to do... load balance across multiple FS
>>>> boxes, and have any machine in the cluster be able to reach a device
>>>> behind a NAT firewall. Hence the need for the proxy. Also, I'm trying
>>>> to keep the proxy relatively "dumb" and put all the logic in the FS boxes.
>>>>
>>>> True I could do the auth on the proxies as well, but then I'm setting up
>>>> another authentication scheme in addition to what is on the FS boxes,
>>>> and then integrating the databases so everything is consistent.
>>>>
>>>> I also have hosts that talk to the FS boxes directly, rather than
>>>> through the proxy. So I can't get rid of auth_acl on FS either, even if
>>>> I do implement it on the proxies. So my setup becomes much more
>>>> complex and potentially brittle.
>>>>
>>>> And all we're really talking about for FreeSWITCH, conceptually
>>>> speaking, is populating a variable with a different IP. We could even
>>>> make it configurable, as to which IP is to be used for the auth-acl.
>>>>
>>>> What are you using for SBCs? (if you are allowed to divulge that) I'm
>>>> currently using OpenSIPS for my proxy.
>>>>
>>>> Thanks,
>>>> Bill
>>>>
>>>> Metik wrote:
>>>>
>>>>
>>>>
>>>>> Why not simply implement this feature in the PROXY itself?
>>>>>
>>>>> FS has a pretty comprehensive security feature set for endpoints that
>>>>> directly register with it.
>>>>>
>>>>> Don't get me wrong, I do agree this is useful especially if you are
>>>>> going to be using your proxies to load balance across multiple FS boxes
>>>>> to create an ad-hoc cluster. I actually have session border controllers
>>>>> that have this feature and use it quite often.
>>>>>
>>>>> -metik
>>>>>
>>>>> Bill W wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hey Metik,
>>>>>>
>>>>>> Thanks for the reply, and the pointers for doing it with xml_curl.
>>>>>>
>>>>>> I'll guess have to do that in the short term, but in my opinion, having
>>>>>> auth-acl be able to work through a proxy is very important as it is a
>>>>>> vital part of a comprehensive security feature set. And it would be
>>>>>> much simpler to implement from an end-user perspective than the
>>>>>> alternative of doing it in xml_curl.
>>>>>>
>>>>>> As a matter of fact, I'm considering offering a bounty for that feature.
>>>>>> What is the going rate for that kind of thing?
>>>>>>
>>>>>> Is anyone out there interested in coding this feature? Or chipping in
>>>>>> for the bounty?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Bill
>>>>>>
>>>>>>
>>>>>> Metik wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> This may be difficult considering that ACL needs to consider the
>>>>>>> original src IP/URI. To do that it, freeswitch would need to do so
>>>>>>> using a header that retains that information (i.e. From, Via, Contact,
>>>>>>> etc.). Which I do not believe is currently possible using auth-acl or
>>>>>>> apply-proxy-acl.
>>>>>>>
>>>>>>> However, you should be able to emulate the behavior using mod_xml_curl
>>>>>>> (and validating against appropriate variables available when using it
>>>>>>> to
>>>>>>> authenticate the request).
>>>>>>>
>>>>>>> see: http://wiki.freeswitch.org/wiki/Mod_xml_curl#Authorization
>>>>>>>
>>>>>>> -metik
>>>>>>>
>>>>>>>
>>>>>>> Bill W wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hey Brian,
>>>>>>>>
>>>>>>>>
>>>>>>>> I've been doing some testing and I am unable to get auth-calls to work
>>>>>>>> through a proxy the way I want them to, even with setting
>>>>>>>> apply-proxy-acl to either the endpoint IP or the proxy IP.
>>>>>>>>
>>>>>>>> I have a multi-tenant system with multiple domains with multiple users
>>>>>>>> in each domain. And I want to restrict a user to an arbitrary CIDR
>>>>>>>> and
>>>>>>>> challenge them for a password. The arbitrary CIDR will vary from UA
>>>>>>>> to
>>>>>>>> UA, and is specified in the directory via the auth-acl parameter.
>>>>>>>>
>>>>>>>> TL,DR; I want to get auth-calls to use the IP of the UA endpoint, not
>>>>>>>> of
>>>>>>>> the proxy.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Bill
>>>>>>>>
>>>>>>>> Brian West wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> it needs to be an ACL from acl.conf or a ip/cidr
>>>>>>>>>
>>>>>>>>> /b
>>>>>>>>>
>>>>>>>>> On Dec 17, 2009, at 5:41 AM, Bill W wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Okay, I added: <param name="apply-proxy-acl" value="true"/> to my
>>>>>>>>>> sofia
>>>>>>>>>> profile and restarted sofia, and still no joy.
>>>>>>>>>>
>>>>>>>>>> I'm on FreeSWITCH Version 1.0.trunk (15764)
>>>>>>>>>> I've got <param name="auth-acl" value="190.218.103.12/32"></param>
>>>>>>>>>> in
>>>>>>>>>> the directory, but I'm still being rejected by the acl:
>>>>>>>>>>
>>>>>>>>>> 2009-12-17 06:04:59.920517 [WARNING] sofia_reg.c:1928 IP
>>>>>>>>>> 64.135.119.105
>>>>>>>>>> Rejected by user acl 190.218.103.12/32
>>>>>>>>>>
>>>>>>>>>> Here's what I believe is the appropriate snippet of the debug output:
>>>>>>>>>> http://pastebin.freeswitch.org/11531
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>> Thanks,
>>>>>>>>>> Bill
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>>
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
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
