[Freeswitch-users] ACLs through proxy

Metik freeswitch-users-list at metik.com
Sat Dec 19 09:47:23 PST 2009


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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>   





More information about the FreeSWITCH-users mailing list