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 Brian West wrote:

use "apply-proxy-acl" on the sofia profile.

/b

On Dec 15, 2009, at 10:58 PM, Bill W wrote:

...

However, having the proxy in the path effectively negates using IP based ACLS.

_______________________________________________ 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

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

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

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

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

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

Then it would appear that my original suggestion to use mod_xml_curl would be best for now and you may need to offer a bounty for this feature as others have suggested. Based on the sofia related snippets presented--I would assume it would be trivial to implement since most of the functionality is already there it just needs to be enhanced for your purpose. It would also be extremely easy to do this in OpenSIPS as well (using blacklists or avpops). Just so that I understand your dilemna, you want to reject an incoming REGISTER associated with a specific user unless it comes from a fixed location and if it does, you want to simply challenge it as usual to prevent toll fraud? I have found that its best to mitigate an attack at ingress before it even makes it to critical infrastructure (media gateways, application/media servers, etc.). -metik Bill W. wrote:

Hey Metik,

Yes. Well, actually, I can have the cidr in two places in the directory.

<user cidr="190.218.97.83/32" id="testphone01"> <params> <param name="auth-acl" value="190.218.97.83/32"></param>

...

From what I understand the cidr= parmeter is used in conjunction with the apply-inbound-acl parameter in the sofia profile to just allow someone to make calls from a certain IP without authenticating.

And from what I understand the auth-acl= parameter is used to restrict a user to a particular cidr, but the user has to authenticate as well.

*The second feature is the one I want to use.* I want to force users to authenticate, but only allow that authentication from a particular cidr as an added measure against toll fraud.

And this appears to be causing the issue. Because once I specify the auth-acl parameter in the directory, sofia-reg enforces that acl. And unfortunately it's using the IP of the proxy, not of the user-agent.

I looked in sofia.c and found this comment: /* * if network_ip is a proxy allowed to send calls, check for auth * ip header and see if it matches against the inbound acl */

And this coincides with my testing. I have <param name="apply-proxy-acl" value="ip_of_proxy"/> in my profile. I have my proxy sending the X-AUTH-IP header (verified with tcpdump). And yet the REGISTER is still being denied.

So it appears that the apply-proxy-acl is set up to work with the apply-inbound-acl ( to allow users from an IP without authenticating)

But that hasn't been carried over to sofia_reg.c, which appears to simply check the IP of who FreeSWITCH is talking to against the auth-acl cidr specified in the directory. (Line 1926)

So I guess the question is, is my analysis correct?

Thoughts anyone?

Thanks, Bill

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

_______________________________________________ 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

From looking at sofia.c, if the ip address of the caller is in apply- proxy-acl, it'll look for the X-AUTH-IP header in the INVITE packet, and use that one for authentication. Is that what you did in your previous tests? Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 17-Dec-09, at 11:02 PM, 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

You need to add that header manually in your OpenSIPS config, FreeSWITCH wont look in record-route/via to try to guess it. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 18-Dec-09, at 10:53 AM, Bill W wrote:

Hello Mathieu,

I assumed that apply-proxy-acl was a modifier of auth-calls, so in my quick tests I just hard-coded the UA IP in the profile.

<param name="auth-calls" value="true"/> <param name="apply-proxy-acl" value="190.218.97.83"/> <!-- IP of UA -->

And I get: 2009-12-18 09:14:28.250929 [WARNING] sofia_reg.c:1928 IP 64.135.119.105 Rejected by user acl 190.218.97.83/32

Where 64.135.119.105 is the IP of my proxy. And actually this is a REGISTER, not an INVITE.

I did a tcpdump, and I'm not seeing the X-AUTH-IP header in the register packet.

I will be incommunicado for the rest of today, but when I get back online, I'll see if I can get my proxy to add the X-AUTH-IP to the REGISTER packet and see if that makes a difference.

Thanks for your help! Bill

Mathieu Rene wrote:

...

From looking at sofia.c, if the ip address of the caller is in apply- proxy-acl, it'll look for the X-AUTH-IP header in the INVITE packet, and use that one for authentication. Is that what you did in your previous tests?

Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca

On 17-Dec-09, at 11:02 PM, 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