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

[Simon J Mudd]

msc at freeswitch.org (Michael Collins) writes:

> 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'm still on that quest. It's just taking some time. I also appreciate the
time several of you are taking in answering what seem to be "silly" questions.

> 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.

Understood. Interestingly I don't see the word "security" mentioned.
Perhaps that's not a primary concern as most "professional FreeSWITCH
installations" are aided by a lot of extra "protection", be that 
quite limited access to external gateways or a lot of time configuring
firewalls before setting up other parts of the system. In that environment
I understand security to be if not less of a concern, probably a well
understood foe.

> #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.

Configuring _any_ system to work properly for a specific use case
requires tuning it, adjusting it and perhaps setting it up in a
different way to the default configuration. My current day job
involves managing a large number of database servers. A default
configuration is pretty useless and the "deployment" of a new server
requires quite a lot of work, and tools so that process can be
automated. Many people would not immediately think it necessary to do
many of the things I do, or configure things the way I do, but for my
environment that's needed.  The software I use however is configured
by default, like lots of internet software, to basically not allow
"outside access" unless you enable that. Enabling it may be very easy
but initially at least the "tighter configuration" means that you
don't open yourself to problems without realising. The people on this
list are likely not to have that problem, but others trying the
software for the first time are. If you want to encourage new users
for small and large installations helping them to avoid shooting
themselves in the foot is always appreciated.

Perhaps just a different point of view. Different use cases (I'm
looking at this from a hobbyist perspective, you probably earn your
living building systems on this software?)

...

> > > 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.*

(1) and (2) have worked with static xml files as I described earlier. I'm
sure there are better ways, but first I need to be comfortable with basic stuff.

...

> 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

mod_curl sounds interesting. I'll take a look. _Needing_ to use something
like this for a "simple" system seems like overkill, even if it provides
more flexibility. Something no doubt for me to look at later. The db backend
is the easy bit: I'm a DBA... And writing code in php or perl doesn't really
worry me.

> > 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.

I've just found out to my detriment that a firewall is worth little if
you poke any outbound holes out to a provider.

If that's such an issue then make a switch so it works both ways.
It's true that switches in vars.xml mean that the users (like me) can be
dumb and do the wrong thing, but I guess that also calls for some sort
of URL reference to explain the "why", and the different options for
those that need to figure out what's going on.

...

> 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 "<!-- xxx -->" 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... :)

Eventually I found this out. I think it took me a couple of months looking 
around and swearing in frustration that I couldn't figure out what the error
was in line 4321.  Again maybe this needs to be pointed out somewhere more prominently,
or if possible the freeswitch logging mentions the fsxml filename itself.

> 3. These are just standard XML comments. They take the form:
> <!-- comment -->
> 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

Then maybe double -- where causing the issue. Thanks for reference.

> 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

Again more for me to read. Thanks again for the pointer.

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

If I understand it that's wrong. Using the "apply-inbound-acl" is to disable
the _need_ for passwords, not add the extra acl in addition to the configured
passwords.

my directory/default/1000.xml now says:

<include>
  <user id="1000">
    <params>
      <param name="password" value="$${default_password}"/>
      <param name="vm-password" value="1000"/>
      <param name="auth-acl" value="localnet.auto"/>
...

And that does what I want. That would be nice in the example config
even if you disable it by default (comment out).

> 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.

Or what lets someone break into your system. Yes, I'm insisting on something
because when I get my phone bill I'm not expecting to be happy. So yes
a sandbox is good, and breaking and tweaking configs is needed. I'm just
[over?] paranoid now. So I "added a gateway" and someone got in through
an extension and started using it... (silly mistake of mine, but easy thing
to happen again)
 
> 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.

I think you misunderstood me.  When I configure a gateway for outgoing
calls then the process seems reasonably clear. What's less clear (and
this was mentioned in today's conference call) is that for an incoming
call to the number that the SIP provider has determined with me that
the call SHOULD only come from them (be that their proxy host, or
maybe a slightly wider network they own). I may be wrong but I don't
see how that is [optionally] enforced with the current default
configuration. That is even if an attacker knows my sip account, or
DID number and password providers password details, if they attempt to
call in from a different host or network I want that call to fail. So
I'd like a way to specify how to tighten incoming calls to that number
to that tighter host/address range. I think a pointer was given to me
on IRC during the conference so I need to check my irc logs, but
it was not obvious to me before.

> 9. See #5

More reading :-)

> 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.

Frankly I can only say thanks. I have not meant to be "hostile" but
perhaps my comments may seem that way to you. The irc, and email
exchanges really are helping and I'm making progress.

...

> *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>

I guess this is similar to the implementation of the solution I found above.
Thanks for showing there's another way to do that.

Simon 

p.s. I know that mail list messages and replies should be kept
short. Sorry this is completely breaking that convention.