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
