[Freeswitch-users] Enabling extensions with passwords and limiting network access via acls (Was: Confusing SIP auth failure logging message?)

Wed Feb 9 07:00:48 MSK 2011

On Tue, Feb 8, 2011 at 4:18 PM, Simon J Mudd <sjmudd at pobox.com> wrote:

> I don't think I got a definitive answer to the question I posed before:
>
> I know you came on to the #freeswitch IRC channel but I don't recall where
you left off in your quest for FreeSWITCH knowledge. I'll provide
information here with links to relevant wiki articles, etc. all inline.
However, let me just put these two points out there for everyone:

#1 - If, when learning FreeSWITCH, you feel overwhelmed because there are so
many different config options, etc. then remember this: FreeSWITCH is
designed for power and flexibility, not simplicity. A carrier-grade,
multi-protocol soft-switch is supposed to be complex.

#2 - The default configuration is just an example of some of the many cool
things you can do with FreeSWITCH. It is not meant to be a turn-key,
out-of-box solution to put into a production environment, even a SOHO
environment. This is a feature, not a bug.

> sjmudd at pobox.com (Simon J Mudd) writes:
>
> ...
>

<snip>

> > This specifies a user for registration who:
> > (1) must provide a password
> > (2) can only register from the given network range
> > (3) is only allowed to make 1 call at a time

> I see that there are ways to implement (3) though it seems that's more on
> a per gateway basis than a per extension basis. That's ok.
>
> What really interests me is implementing (1) _and_ (2) together.  Is this
> possible? If not it would certainly be a nice new feature.
>

This is definitely possible. There are two ways to do it that I can think
of:
#1 - The "proper" way with mod_xml_curl
#2 - The less proper but still quite functional way of using a user's
channel variables and dialplan.*

Either option requires a bit of reading up. The good news is that setting
the user information in the directory magically makes FS ready to do auth
challenges for calls and user registrations.

For more information on mod_xml_curl see:
http://wiki.freeswitch.org/wiki/Mod_xml_curl
Also see Raymond's samples in the freeswitch-contrib repo:
http://fisheye.freeswitch.org/browse/freeswitch-contrib/intralanman/PHP/fs_curl

> Perhaps the default FreeSWITCH configuration should limit access to
> the default extensions to be registered only from the networks defined
> in localnet.auto.  This reduces exposure to external bad
> software.
>
Many people don't want this limitation turned on by default. If we did this
then a lot of people would be asking for the ability to have external phones
be able to access FreeSWITCH by default. Besides, there are other
alternatives, such as using a firewall.

> Even if I can configure this extra limitation myself manually I'd be
> happy as this would basically leave me more comfortable with
> FreeSWITCH running unattended. I'm not confident to do that now if I
> configure any gateways due to the issues I've had before.
>
Understood. It is always best to know your VoIP before you throw it out on
the public Internet.

Your blog had several other issues so I'll number them here and then comment
on them below.
Questions:

1. Default FreeSWITCH logging maybe too verbose
2. XML file breakage
3. Relatedly, comments need to be in "" format
4. The external profile should log auth failures by default
5. FreeSWITCH should have some sort of rate-limiting
6. It should be more obvious how to configure network ACLs for for
extensions, and these should be configured by default
7. For registration, a client can use FreeSWITCH's IP address as well as
domain name
8. "For trunk connections if you have a DID number you expect the VoIP
provider to call you..."
9. Allow rate-limiting to/from a gateway or extension

Answers:

1. This goes back to FreeSWITCH being a massively huge piece of software
with lots of configuration options. Having verbose debugging is very handy.
It is much better for a new person to have too much information at first and
then learn about what logging to turn off. The other alternative is for a
new person to come around with a question about something that happened and
not have any logs to help debug. Log files can be archived or deleted, but
the information that never got logged is worthless.

2. XML "file breakage" is well-documented here:
http://wiki.freeswitch.org/wiki/Debugging_Freeswitch#Chasing_down_XML_errors
If you wanted to you could take the aggregated file (freeswitch.xml.fsxml)
and put it in conf/freeswitch.xml as the only config file. Of course, now
you're editing a 4500 line XML file... :)

3. These are just standard XML comments. They take the form:

The XML standard dictates that you have two dashes. (Your example seems to
show single dashes.) The XML standard also states that you may not nest
comments, nor may you include "--" inside of a comment. See
http://www.w3.org/TR/REC-xml/#sec-comments for more info

4. This is a reasonable suggestion. We have a saying: "patches accepted". If
anyone has a moment to implement *AND TEST* this please do so and send us a
patch on Jira.

5. Rate-limiting is absolutely possible in FreeSWITCH, and it is not limited
to SIP traffic. Pretty much anything you can think of can be rate-limited
using mod_limit. More information here:
http://wiki.freeswitch.org/wiki/Mod_limit

6. Not sure how to make it more obvious than this:
http://wiki.freeswitch.org/wiki/Acl#Users

7. We allow both IP and domain name by default to lower the barrier to
entry. The default config is supposed to "just work" in a sandbox so that
new users can learn. One great way to learn is by setting up a system and
then making mods to the default config and see what breaks.

8. This is a fun one... What you ask for is something that would work in an
ideal situation, however SIP is involved so idealism must give way to
realism. Most providers will blow up and die if you send them 401's or 407's
so that's not a logical choice for the default. (Again, nothing preventing
you from modifying the default configs to suit your personal needs.) You can
also use ACLs to limit the source of incoming calls, but then you run the
risk of them reconfiguring and changing IP addresses. As long as you are
prepared for that scenario then you're fine, but most new users probably
could do without us adding that burden to them by default.

9. See #5

I hope we haven't scared you off! I'm sure that you can (and will) overcome
all of your challenges in configuring FreeSWITCH for your needs. The
community is here to assist.

Regards,
Michael S Collins (IRC: mercutioviz)

*BONUS CONTENT:
Here's an example of limiting a user's IP address. Add a line like this to
your user's XML file:
<variable name="allowed_ipaddrs" value="^(192\.168\.1\.|10\.10\.16\.161)"/>
This is a regex that matches an exact address (10.10.16.161) or matches a
partial IP address (192.168.1.x)

Then do something like this in your dialplan:
  <extension name="check user's IP address" continue="true">
    <condition field="network_addr" expression="${allowed_ipaddrs}">
      <action application="log" data="WARNING IP Addr test passed"/>
      <anti-action application="log" data="ERR IP Addr test is an EPIC
FAIL"/>
      <anti-action application="answer"/>
      <anti-action application="sleep" data="1000"/>
      <anti-action application="playback"
data="ivr/ivr-all_your_call_are_belong_to_us.wav"/>
      <anti-action application="hangup"/>
    </condition>
  </extension>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110208/fcfad36f/attachment-0001.html 