[Freeswitch-users] INVITE DoS Prevention

Mon Feb 21 11:41:54 MSK 2011

BTW.. here is a link :-)

http://etel.wiki.oreilly.com/wiki/index.php/SIP_DoS/DDoS_Mitigation

On Feb 21, 2011, at 12:04 AM, Spencer Thomason wrote:

> Thanks for the info!  Yes it would be great if Freeswitch logged  
> this info somewhere but this firewall script was was I was trying to  
> accomplish. :-)  I was trying to do this with the minimal amount of  
> overhead and I think that might be the ticket.  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.  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.  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.
>
> Thanks again,
> Spencer
>
> On Feb 20, 2011, at 11:22 PM, jay binks wrote:
>
>> Howdy
>>
>>    mmm I just had a quick look at mod_sofia , and unfortunatly it  
>> looks like the channel is hungup after the challenge is sent.   But  
>> my guess is that there HAS To be a list or similar somewhere that  
>> tracks endpoints waiting for challenge responses.
>>
>> Ill see if can track it down and submit a patch, because I too  
>> would like to see this at least logged.
>>
>> as for rate-limiting responses you can have iptables drop packets  
>> over X number of invites per sec ...
>> ( But they are dropped silently at the Firewall - Kristians SIP  
>> Ratelimiter has this in it )
>>
>> or you can use mod_limit to allow X number of invites per sec  
>> also,  you would want to tell FS to hit the dialplan before codec  
>> negotiation though to do that nice and early in the piece.
>>
>> Jay
>>
>> On Mon, Feb 21, 2011 at 5:10 PM, Spencer Thomason <spencer at 5ninesolutions.com 
>> > wrote:
>> Yes, that works great if they respond to the challenge with a failed
>> auth. But the scenario I'm trying to prevent is if they just send the
>> INVITE and never respond to the challenge.  Fail2Ban will not work as
>> every endpoint will initially send an INVITE and receive a challenge.
>> Legit calls will then respond correctly and not be logged as a SIP
>> auth failure but every call that is challenged will show up as SIP
>> auth challenge in the logs so there is no regex to differentiate
>> between legit an non legit traffic.
>>
>> Spencer
>>
>> On Feb 20, 2011, at 10:39 PM, Ken Rice wrote:
>>
>> > Fail2Ban ... This is block an IP with too many failed attempts from
>> > something like SipVicious pretty quickly
>> >
>> >
>> > On 2/20/11 11:07 PM, "Spencer Thomason"  
>> <spencer at 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 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> -- 
>> Sincerely
>>
>> Jay
>
> _______________________________________________
> 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/20110221/40bb2d98/attachment.html 