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.