[Freeswitch-users] ACLs through proxy

Bill W. freeswitch at aastral.net
Fri Dec 18 21:37:24 PST 2009 

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

More information about the FreeSWITCH-users mailing list