[Freeswitch-users] INVITE DoS Prevention

[Spencer Thomason]

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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110220/7699726b/attachment-0001.html