<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks for the info! &nbsp;Yes it would be great if Freeswitch logged this info somewhere but this firewall script was was I was trying to accomplish. :-) &nbsp;I was trying to do this with the minimal amount of overhead and I think that might be the ticket. &nbsp;The cool thing about having Freeswitch log it and then pick it up with Fail2ban would be that you could define the limit per user/IP. &nbsp;Say for instance you are using Freeswitch as an SBC and if the invite matches a user or an IP that is known, that limit could be much higher than an unknown IP or user. &nbsp;That would keep you from having to define a limit that is overly "safe" to prevent blocking real traffic especially if you are talking about a lot of traffic.<div><br></div><div>Thanks again,</div><div>Spencer</div><div><br><div><div><div>On Feb 20, 2011, at 11:22 PM, jay binks wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Howdy</div><div><br></div><div>&nbsp;&nbsp; mmm I just had a quick look at mod_sofia , and unfortunatly it looks like the channel is hungup after the challenge is sent. &nbsp;&nbsp;But my guess is that there HAS To be a list or similar somewhere that tracks endpoints waiting for challenge responses.</div> <div><br></div><div>Ill see if can track it down and submit a patch, because I too would like to see this at least logged.</div><div><br></div><div>as for rate-limiting responses you can have iptables drop packets over X number of invites per sec ...&nbsp;</div> <div>( But they are dropped silently at the Firewall - Kristians SIP Ratelimiter has this in it )&nbsp;</div><div><br></div><div>or you can use mod_limit to allow X number of invites per sec also, &nbsp;you would want to tell FS to hit the dialplan before codec negotiation though to do that nice and early in the piece.</div> <div><br></div><div>Jay</div><div><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 5:10 PM, Spencer Thomason <span dir="ltr">&lt;<a href="mailto:spencer@5ninesolutions.com">spencer@5ninesolutions.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Yes, that works great if they respond to the challenge with a failed<br> auth. But the scenario I'm trying to prevent is if they just send the<br> INVITE and never respond to the challenge. &nbsp;Fail2Ban will not work as<br> every endpoint will initially send an INVITE and receive a challenge.<br> Legit calls will then respond correctly and not be logged as a SIP<br> auth failure but every call that is challenged will show up as SIP<br> auth challenge in the logs so there is no regex to differentiate<br> between legit an non legit traffic.<br> <font color="#888888"><br> Spencer<br> </font><div><div></div><div class="h5"><br> On Feb 20, 2011, at 10:39 PM, Ken Rice wrote:<br> <br> &gt; Fail2Ban ... This is block an IP with too many failed attempts from<br> &gt; something like SipVicious pretty quickly<br> &gt;<br> &gt;<br> &gt; On 2/20/11 11:07 PM, "Spencer Thomason" &lt;<a href="mailto:spencer@5ninesolutions.com">spencer@5ninesolutions.com</a>&gt;<br> &gt; wrote:<br> &gt;<br> &gt;&gt; Hi,<br> &gt;&gt; We run hosted Freeswitch instances in VMs with the internal profile<br> &gt;&gt; on<br> &gt;&gt; port 5060 connecting to clients mostly behind NAT and then the<br> &gt;&gt; external profile connecting to our proxies only. &nbsp;Protecting the<br> &gt;&gt; external profile its straightforward.. we only allow traffic to/from<br> &gt;&gt; our proxies at the firewall level. &nbsp;But protecting the internal<br> &gt;&gt; profile seems to be a bit more difficult because the UACs could be<br> &gt;&gt; theoretically anywhere on the network.<br> &gt;&gt;<br> &gt;&gt; I'm currently using Fail2Ban to prevent brute force registration and<br> &gt;&gt; INVITEs on auth failures, e.g.:<br> &gt;&gt; failregex = \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(REGISTER\)<br> &gt;&gt; on sofia profile \'\w+\' for \[.*\] from ip &lt;HOST&gt;<br> &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(INVITE\)<br> &gt;&gt; on sofia profile \'\w+\' for \[.*\] from ip &lt;HOST&gt;<br> &gt;&gt;<br> &gt;&gt; My question is, since its part of a normal SIP dialog to challenge<br> &gt;&gt; the<br> &gt;&gt; INVITE, is there any way to prevent a possible DoS from just sheer<br> &gt;&gt; volume of incoming INVITEs on an Internet facing server<br> &gt;&gt; automatically. &nbsp;I.e., If you block the logged challenge, you'd block<br> &gt;&gt; all legitimate INVITEs and registrations. &nbsp;Since its UDP traffic I<br> &gt;&gt; couldn't come up with a way to do it automatically at the iptables<br> &gt;&gt; level. i.e. number of concurrent connections. &nbsp;Is there some option<br> &gt;&gt; to<br> &gt;&gt; just not respond if a client is sending a number of requests over a<br> &gt;&gt; certain threshold? &nbsp;It might not stop them from sending the traffic<br> &gt;&gt; but pretty soon they'd get the idea that it wasn't going to go<br> &gt;&gt; anywhere. &nbsp;My concern is say there are 50 Freeswitch instances on a<br> &gt;&gt; box (albeit 8 core, 32GB ram, 8 15K raid 10 storage) and someone<br> &gt;&gt; starts sending thousands of rouge INVITEs to every VM on a physical<br> &gt;&gt; box that the CPU load from just challenging the incoming INVITEs<br> &gt;&gt; would<br> &gt;&gt; create a DoS. &nbsp;We the logs regularly to try to catch people doing<br> &gt;&gt; this<br> &gt;&gt; sort of thing and drop them at a router upstream of the core network,<br> &gt;&gt; but I'd like to have it happen without human intervention. &nbsp;Have I<br> &gt;&gt; completely over thought this and am missing something obvious?<br> &gt;&gt;<br> &gt;&gt; Thanks,<br> &gt;&gt; Spencer<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; _______________________________________________<br> &gt;&gt; FreeSWITCH-users mailing list<br> &gt;&gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br> &gt;&gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br> &gt;&gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br> &gt;&gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br> &gt;<br> &gt;<br> &gt;<br> &gt; _______________________________________________<br> &gt; FreeSWITCH-users mailing list<br> &gt; <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br> &gt; <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br> &gt; UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br> &gt; <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br> &gt;<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> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Sincerely<br><br>Jay<br> </div></blockquote></div><br></div></div></body></html>