Hi Régis, We currently use openvz. Previously we used Xen and then BSD jails. Every one has their ups and downs. As many people will tell you, timing is critical in VoIP applications and by using OpenVZ there is only one kernel loaded and the VMs all run bare metal. This is a much more efficient way of running several VMs if they are all of a similar OS because you don't need to waste a bunch of RAM and CPU cycles just loading 30 copied of the kernel into memory and dealing with paging etc.. Also this makes administration much easier because of separate filesystems for each VM, the root of each VM is located somewhere in the host's filesystem. This is a big plus when you go to back up your hardware node. What we do is put all the VMs on an LVM partition, make a snapshot and use rsync to back up just the changes. It was a major pain with several independent LVM partitions or "virtual" file based partitions in Xen. KVM or any true virt platform would require the same, a dedicated partition for each VM. And CPU scaling works well with openvz allowing us to save on the electric bill and cooling costs. The downside is if there is a kernel panic, its one kernel and the whole world goes with it. BSD Jails was cool but didn't allow the per client resource control we were looking for. Our experience with openvz has been solid with a couple of machines up well over a year. We currently use Centos but we've modified it to the point where its basically our own in house distro with updates to some of the core packages since RH stays so far behind. (for good measure :-)) This allows us to pick and choose which packages we'd like to update and we make available our own repo which a simple yum update pulls down everything from a local mirror. If you are interested: http://repo.5ninesolutions.com . Having said that, there is a lot of time that goes into maintaining some of the out of distro stuff so we are currently looking at something that stays a little more current.. I.e. RH 6 has been out since Nov and I haven't seen a beta for Centos 6.. but thats a whole can of worms.. Spencer On Feb 20, 2011, at 11:35 PM, Régis MARTIN wrote:

Hi Spencer,

...

We run hosted Freeswitch instances in VMs Nothing related with your question, but can you say me what hypervisor do you use to run freeswitch virtualized (VMware ? KVM ? Xen? OpenVZ ? other .. ?). ? What's is your linux distrib under too ?

I'm looking to virtualize some of mine under KVM and I wonder if it works like standard host and looking to similar experience.

Thanks in advance if you could confirm that to me.

Regards,

2011/2/21 Spencer Thomason <spencer@5ninesolutions.com> Hi, We run hosted Freeswitch instances in VMs with the internal profile on port 5060 connecting to clients mostly behind NAT and then the external profile connecting to our proxies only. Protecting the external profile its straightforward.. we only allow traffic to/from our proxies at the firewall level. But protecting the internal profile seems to be a bit more difficult because the UACs could be theoretically anywhere on the network.

I'm currently using Fail2Ban to prevent brute force registration and INVITEs on auth failures, e.g.: failregex = \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(REGISTER\) on sofia profile \'\w+\' for \[.*\] from ip <HOST> \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(INVITE\) on sofia profile \'\w+\' for \[.*\] from ip <HOST>

My question is, since its part of a normal SIP dialog to challenge the INVITE, is there any way to prevent a possible DoS from just sheer volume of incoming INVITEs on an Internet facing server automatically. I.e., If you block the logged challenge, you'd block all legitimate INVITEs and registrations. Since its UDP traffic I couldn't come up with a way to do it automatically at the iptables level. i.e. number of concurrent connections. Is there some option to just not respond if a client is sending a number of requests over a certain threshold? It might not stop them from sending the traffic but pretty soon they'd get the idea that it wasn't going to go anywhere. My concern is say there are 50 Freeswitch instances on a box (albeit 8 core, 32GB ram, 8 15K raid 10 storage) and someone starts sending thousands of rouge INVITEs to every VM on a physical box that the CPU load from just challenging the incoming INVITEs would create a DoS. We the logs regularly to try to catch people doing this sort of thing and drop them at a router upstream of the core network, but I'd like to have it happen without human intervention. Have I completely over thought this and am missing something obvious?

Thanks, Spencer

_______________________________________________ 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