[kwlug-disc] AsteriskNow?

[unsolicited]

Lori Paniak wrote, On 07/31/2010 6:00 PM:
> On Sat, 2010-07-31 at 15:15 -0400, unsolicited wrote:
>> John Van Ostrand wrote, On 07/31/2010 8:59 AM:
>>> ----- Original Message -----
>>>
>>>> All the Asterisk-based distros I've seen suffer from this
>>>> near-fatal flaw. It is astounding how poor their commitment to
>>>> system security is.
>>>>
>>>> While starting with a bare Debian install and building your own
>>>> VoIP box would solve the security problem(s), I think you would
>>>> be better off using a porous distro and adding firewall software.
>>>> Then you can restrict access until you are satisfied. I use
>>>> Shorewall to give a (more) user-friendly interface to iptables.
>>>> Shorewall has great documentation - especially for typical cases.
>>>> Just open up UDP ports 5060-5080 for SIP and 10000-30000 for RTP
>>>> and you should have a functional, secure VoIP system.
>>> I agree with Lori. Starting with the distro and turning off or
>>> securing the things you want is a fast way to success. A firewall
>>> alone won't work for you if you want one or more of the web-based
>>> applications.
>>>
>>> Run netstat -a to see which ports are listening and go from there.
>>> Then inspect your apache config and see what you have to secure or
>>> turn off.
>>>
>>> I find turning things off, checking configs and changing passwords
>>> is far easier than integrating all that software.
>> How un/reasonable is it to consider oneself 'sufficiently' 'safe' in 
>> this (distro) situation? (Behind a firewall, and only the mentioned 
>> ports opened and directed to the box.)
>>
> 
> If you only open the UDP ports I specified, your system will not appear
> on TCP port scans.  The only outstanding security issue that I know of
> is that of VoIP phreaks who try to gain access to insecure extensions on
> your Asterisk system.  This can be cured by (1) setting ACLs and (2)
> strong SIP registration passwords.  If all your extensions are on the
> LAN side of your system and you take these precautions, I don't see how
> it can be compromised from the outside.

I'm far less worried about phone phreaks (high telephone bill) than 
people getting in and trashing the systems. Repairing or 
reestablishing the systems would be more painful, I suspect.

>> Assuming no internal hardware such as line cards, in the home (with 2 
>> or 3 ATA devices, 1 POTS, perhaps 2 'extensions' which might be 
>> multi-handset cordless phones), how un/reasonable is it to expect 
>> 'sufficiently' acceptable performance when running such distros within 
>> a vm? I guess I'm assuming the hardware is dual-core, and 2 - 4 GB 
>> memory. I'm not assuming it is the only vm, but I guess I'm assuming 
>> sufficient resources exist to run each vm in a 'reasonable' manner.
>>
> 
> Historically, running VoIP in a VM has been problematic due to timing
> issues.  This may be a thing of the past, but I suspect you will want to
> run your VoIP system on bare metal and put everything else in VMs.  So
> long as you have no more than a concurrent call or two and not much disk
> thrashing, you will probably get acceptable performance from the setup
> you describe.
> 
> If you've got this server hardware currently running, the barrier to
> starting up a trixbox VM is pretty low. You could test internal
> performance like echo test, voice prompts and voicemail to see how it
> works.  If you find that acceptable, you can add in a DID from Unlimitel
> for $3.50/month and evaluate external call performance.
> 
>> Perhaps I'm asking the impossible here, given everyone will have their 
>> own definitions for 'sufficiently', 'safe', and 'reasonable'. Perhaps 
>> 'reasonable' is not ecstatic, but also not particularly unhappy. (JJ 
>> said to me a long, long, time ago "You pick it up, you get dial tone." 
>> - you're happy, or, at least, satisfied, and not unhappy.)
>>
> 
> That's the beauty of open source:  You can pull the security blanket up
> as high as it takes to feel comfortable.  You do not have to settle for
> someone else's definition of secure.  Reasonable performance is more
> difficult.

Sorry, that's not helpful - as the uninitiated have no idea how high 
is high enough, yet is 'sufficiently' high. As, who the heck knows 
what 'sufficiently' is until after the fact when they find out it 
wasn't sufficient enough.

I suspect, though, that that is the cross that everyone has to bear.

>> I have a suspicion that I could run a mythbuntu (with kde), plus 2 or 
>> 3 vms (one of these distros, and egroupware, and courier e-mail either 
>> with egroupware or in its own vm) and be 'sufficiently' satisfied. 
>> When performance is insufficient, perhaps I'm streaming HD in and out 
>> simultaneously, move egroupware/courier to a vm on another machine, 
>> and keep going. Is this a fantasy world?
> 
> Is mythbuntu driving a display?  Then you're probably asking too much.
> If it is just a backend server and not transcoding, then you might be
> able to get away with it.  With lots of disk and network I/O from HD
> streams, it gets even more dicey. Typically, you'll want dedicated
> hardware for these situations.
> 
> Of course, that's my take on your questions.  I have never run mythbuntu
> with KDE on my Asterisk system.

OK, but ...

(I have nothing running at the moment.)

Mythbuntu would be driving a display. It (*) can't be in a vm because 
it must access physical hardware (video) quite hard. Asterisk should 
only be playing tcp/ip traffic cop here between unlimitel and the 
ata's. I wouldn't have expected it to be disk intensive, or much 
affected by disk activity. I'm not disputing what you've said, it's 
just not intuitive to the uninitiated that it would be disk intensive.

- since this is all ip, the timing issues you mention revolve around 
voice quality, not session establishment or call management?


Mythbuntu could be just a back end on that box, and thus run in a vm. 
But now you're back to two sets of hardware. Which is not necessarily 
bad, it's just one wants to load up any one box 'sufficiently' before 
establishing another one. The other major need would be lots of disk 
space for rsync (on a separate box), so it's more a matter of figuring 
out what an appropriate load balance between the two boxes is, let 
alone letting the two (myth and asterisk) fight it out over who wants 
to be the gateway.

I suspect the way to build out is the way I described, and if/when the 
performance is 'insufficient', be it video, or voice (call), build out 
to the other box, as you suggest.

- and from the comments in this thread, the other box should start 
with Trixbox, rather than just Kubuntu, before adding the large disks 
for a replica store. Mind you, at that point, it could also become a 
myth back end, at which point the load level on the first box (which 
would have started as a hybrid (front and back ends) drops - and we're 
back to square one.

Circles.