You can do so in freeswitch but sometimes it's better to do it in the firewall. For example it uses far fewer resources to block someone in the firewall. It's also easier to block scanners such as friendly-scanner in the firewall. Steve on iPhone On 7 Feb 2011, at 07:31, Simon J Mudd <sjmudd@pobox.com> wrote:

On Mon, Feb 07, 2011 at 12:22:36AM +0100, Simon J Mudd wrote:

...

I've been looking at trying to configure tighter controls for extensions that register.

Looking at http://wiki.freeswitch.org/wiki/Acl I see the comment lower down:

sip_profiles

... Should you want to protect your FreeSWITCH installation from being contacted by some IP addresses, you will need to setup some firewall rules. To protect your installation, you can look at QoS.

I'm confused. I understand that a firewall can be configured to drop/allow certain packages but given that FreeSWITCH does have acls it seems unusual to me that you can do this directly in FreeSWITCH.

That is I have an Asterisk configuration which I am trying to migrate from and can easily configure in sip.conf:

[1000] username=1000 type=friend secret=1234567890 context=xxxxxx host=dynamic registersip=yes deny=0.0.0.0/0.0.0.0 permit=88.100.50.0/255.255.255.0 -- this is not a real network range but you get the idea. nat=yes call-limit=1 ...

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

Basically I want to mimic this functionality.

I'm assuming that FreeSWITCH acls would be the way to do this. The examples on the wiki don't seem to suggest this is possible. Could someone help provide an example of if/how this would be done in FreeSWITCH?

Thanks,

Simon

_______________________________________________ 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

steveayre@gmail.com (Steven Ayre) writes:

You can do so in freeswitch but sometimes it's better to do it in the firewall.

Perhaps. If it's possible to do it in FreeSWITCH how can it be done? I can't find the "how" in the wiki documentation which is why I was asking.

For example it uses far fewer resources to block someone in the firewall. It's also easier to block scanners such as friendly-scanner in the firewall.

Are there examples of this on the wiki? That is iptables rules intended for a system such as FreeSWITCH which log problems. Some things may make more sense in the firewall (or on the FreeSWITCH server itself) but I'm still inclined to think that other stuff should be provided by the application itself, even if not enabled by default if this uses up "precious resources" on a busy system. On a SOHO type system I'd personally configure things in one place as that is easier to maintain. Simon

I don't think I got a definitive answer to the question I posed before: sjmudd@pobox.com (Simon J Mudd) writes: ...

That is I have an Asterisk configuration which I am trying to migrate from and can easily configure in sip.conf:

[1000] username=1000 type=friend secret=1234567890 context=xxxxxx host=dynamic registersip=yes deny=0.0.0.0/0.0.0.0 permit=88.100.50.0/255.255.255.0 -- this is not a real network range but you get the idea. nat=yes call-limit=1 ...

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

sjmudd@pobox.com (Simon J Mudd) writes:

I don't think I got a definitive answer to the question I posed before:

sjmudd@pobox.com (Simon J Mudd) writes:

...

...

That is I have an Asterisk configuration which I am trying to migrate from and can easily configure in sip.conf:

[1000] username=1000 type=friend secret=1234567890 context=xxxxxx host=dynamic registersip=yes deny=0.0.0.0/0.0.0.0 permit=88.100.50.0/255.255.255.0 -- this is not a real network range but you get the idea. nat=yes call-limit=1 ...

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.

Yes, it is. I finally figured that I need something like: === snip 1000.xml === <include> <user id="1000"> <params> <param name="password" value="$${default_password}"/> <param name="vm-password" value="1000"/> <!-- limit this extension to be used from network 10.1.2.0/24 --> <!-- <param name="auth-acl" value="10.1.2.0/24"/> --> </params> <variables> <variable name="toll_allow" value="domestic,international,local"/> <variable name="accountcode" value="1000"/> <variable name="user_context" value="default"/> <variable name="effective_caller_id_name" value="Extension 1000"/> <variable name="effective_caller_id_number" value="1000"/> <variable name="outbound_caller_id_name" value="$${outbound_caller_name}"/> <variable name="outbound_caller_id_number" value="$${outbound_caller_id}"/> <variable name="callgroup" value="techsupport"/> </variables> </user> </include> ==== snip ==== So thanks. That's good. Can this somehow be done at a global level in directory/default.xml in the <params> section? Would be nice to comment these options in both places so they are easier to find and apply if needed.

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.

So an option like <param name="auth-acl" value="localnet.auto"/> would be a nice option to have as this is safe and "auto-configure" at the same time. In fact it seems that this also works: I have 2 phones configured to register one configured with the ip-based acl, the other with the name-based acl. 2011-02-09 00:01:18.332336 [DEBUG] sofia_reg.c:2370 IP [10.1.2.35] passed ACL check [localnet.auto] 2011-02-09 00:01:18.361773 [DEBUG] sofia_reg.c:2370 IP [10.1.2.35] passed ACL check [10.1.2.0/24] That's even better. _Please_ add this to the default configuration files, even if it's commented out, as it makes it easy to see how to tighten down on the config if that is wanted. Simon

Hi Brian, brian@freeswitch.org (Brian West) writes:

So while you can buy a gun and bullets who's fault is it when you get shot in the foot? Same thing really.

I'm not sure I like examples with guns as there are often very opposing points of view on topics like that. However, it is true that with all software you can configure it incorrectly and cause yourself problems. Ideally that's something you want to avoid if possible.

Our dialplan is rather secure since I designed it and I fully understand how our security model works.

So you understand how to _avoid_ mistakes and what _not_ to do. The issue I've been having is that for me it's not so obivous when I'm making those obvious mistakes and doing things that are not sensible. I have tried to read the documentation. I believe that if it can happen to me others will have similar difficulties. Thus the learning curve even to setup something "simple" is exremely steep.

Our default is just an example of how to use FreeSWITCH.

Of course. The software is flexible so giving people a starting point is helpful. Providing pointers (if that's possible about the good things to do and the things to avoid) aids us even more.

I could do a service and just delete it all and leave it up to you to figure it all out but I feel learning by example is a great way to see how to use the software.

Yes, and I for one appreciate the example configuration. Having said that the page http://wiki.freeswitch.org/wiki/SIP_Provider_Examples seems to imply that if I add external gateways they should be added under conf/sip_profiles/external/provider.xml external.xml says: <profile name="external"> <!-- http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files --> <!-- This profile is only for outbound registrations to providers --> <gateways> <X-PRE-PROCESS cmd="include" data="external/*.xml"/> </gateways> ... which seems to confirm this idea, yet internal.xml says: <profile name="internal"> ... <!-- Outbound Registrations --> <gateways> <X-PRE-PROCESS cmd="include" data="internal/*.xml"/> </gateways> ... It's not clear to me where the providers should go. I've added them under external/ but I think that's wrong. Understand why I'm confused? Also I see from: http://wiki.freeswitch.org/wiki/Getting_Started_Guide#Configuring_FreeSWITCH comments about: Some common extensions for testing 1000, 1001, ..., 1019 - Generic SIP extensions No mention here that these extensions are "reachable from outside". While there's nothing specifically bad about them being reachable from outside if that's not the behaviour you want and you think they are internal extensions only you may have a surprise. I'm reluctant to go editing the wiki because I don't fully understand things but perhaps a "(also reachable from outside)" comment would be useful and perhaps a similar comment in the configuration files. The files directory/default/10XX.xml "seem" to be internal, and there's no indication that this might not be the case. Yes, I've _finally_ figure out that this because of the configuration in dialplan/public.xml. It's really hard to put this all together unless you understand the meaning and usage of all the configuration files. I can: * suggest patches to the config files to add comments if that would help. * edit the wiki if I'm _sure_ that the changes I make are correct but I'm rather reluctant to jump in when I'm not the one who really understands and others do much better. I'm silly trying to point out _I_ I'm having trouble, why I'm having trouble and hoping that this will aid in the end to improving the documentation so that more people can use this software. Regards, Simon

msc@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_c...

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.

msc@freeswitch.org (Michael Collins) writes: ...

No. This is just saying that there was a challenge, not that there was a failure. There is already a failure detection routine. To test it, setup a SIP client with an incorrect password. You'll see two log lines like this:

2011-02-07 12:23:28.490029 [WARNING] sofia_reg.c:1247 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1002@10.10.16.161] from ip 10.10.16.161 2011-02-07 12:23:29.035950 [WARNING] sofia_reg.c:1247 SIP auth challenge (REGISTER) on sofia profile 'internal' for [1002@10.10.16.161] from ip 10.10.16.161 2011-02-07 12:23:29.240695 [WARNING] sofia_reg.c:1205 SIP auth failure (REGISTER) on sofia profile 'internal' for [1002@10.10.16.161] from ip 10.10.16.161

This allows you to differentiate between the mere fact that an auth challenge was sent to the SIP client vs. the SIP client failing to auth. (Someone asked for that differentiation a while back - I don't know who or why...)

Thanks for the clarification. I must have missed the other message. Having both makes sense for example if used with fail2ban. Simon