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.<div>
<br></div><div>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 ??</div><div><br></div><div>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).</div>
<div><br></div><div>Brent<br><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 3:07 PM, Spencer Thomason <span dir="ltr"><<a href="mailto:spencer@5ninesolutions.com">spencer@5ninesolutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
We run hosted Freeswitch instances in VMs with the internal profile on<br>
port 5060 connecting to clients mostly behind NAT and then the<br>
external profile connecting to our proxies only. Protecting the<br>
external profile its straightforward.. we only allow traffic to/from<br>
our proxies at the firewall level. But protecting the internal<br>
profile seems to be a bit more difficult because the UACs could be<br>
theoretically anywhere on the network.<br>
<br>
I'm currently using Fail2Ban to prevent brute force registration and<br>
INVITEs on auth failures, e.g.:<br>
failregex = \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(REGISTER\)<br>
on sofia profile \'\w+\' for \[.*\] from ip <HOST><br>
\[WARNING\] sofia_reg.c:\d+ SIP auth failure \(INVITE\)<br>
on sofia profile \'\w+\' for \[.*\] from ip <HOST><br>
<br>
My question is, since its part of a normal SIP dialog to challenge the<br>
INVITE, is there any way to prevent a possible DoS from just sheer<br>
volume of incoming INVITEs on an Internet facing server<br>
automatically. I.e., If you block the logged challenge, you'd block<br>
all legitimate INVITEs and registrations. Since its UDP traffic I<br>
couldn't come up with a way to do it automatically at the iptables<br>
level. i.e. number of concurrent connections. Is there some option to<br>
just not respond if a client is sending a number of requests over a<br>
certain threshold? It might not stop them from sending the traffic<br>
but pretty soon they'd get the idea that it wasn't going to go<br>
anywhere. My concern is say there are 50 Freeswitch instances on a<br>
box (albeit 8 core, 32GB ram, 8 15K raid 10 storage) and someone<br>
starts sending thousands of rouge INVITEs to every VM on a physical<br>
box that the CPU load from just challenging the incoming INVITEs would<br>
create a DoS. We the logs regularly to try to catch people doing this<br>
sort of thing and drop them at a router upstream of the core network,<br>
but I'd like to have it happen without human intervention. Have I<br>
completely over thought this and am missing something obvious?<br>
<br>
Thanks,<br>
Spencer<br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>--<br>Brent Paddon<br><br>Director | Over the Wire Pty Ltd <a href="mailto:brent.paddon@overthewire.com.au">brent.paddon@overthewire.com.au</a> | <a href="http://www.overthewire.com.au">www.overthewire.com.au</a><br>
Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0400 2400 54<br>
</div>