We run a somewhat similar sounding setup.  We wrote some code that grabs the /32 from the fail2ban instance running on each VM, and automatically puts that /32 into a BGP blackhole sink which stops traffic to the entire network for that /32.

You could look to do something similar, either BGP blackholing it or if you have a single upstream, use something like expect to insert a firewall rule ??

With that said, it could be nice for some of this to exist in FS itself (as you say, slowing down responses over certain thresholds).

Brent

On Mon, Feb 21, 2011 at 3:07 PM, Spencer Thomason <spencer@5ninesolutions.com> wrote:
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



--
--
Brent Paddon

Director | Over the Wire Pty Ltd brent.paddon@overthewire.com.au | www.overthewire.com.au
Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0400 2400 54