[Freeswitch-users] INVITE DoS Prevention

Tue Feb 22 01:55:57 MSK 2011

Yes, and that works well.  Initially I was trying to guard against a  
bunch of INVITEs without auth replys.  For the time being I've set up  
a separate fail2ban filter that looks at the invite challenges and  
only blocks someone if its extremely high in a short period of time.    
I still have to figure out how many of these INVITEs without auths the  
systems can handle because when you've got several instances going  
just the disk activity from the logs becomes problematic if there is a  
massive spike.  Logging the auth timeouts seems to be the ideal  
solution because you could then drop the timeouts without affecting  
legit traffic.

Spencer

On Feb 21, 2011, at 2:33 PM, jay binks wrote:

> could you not just modify your fail2ban regex and set the threshold  
> for Register Auths in fail2ban ?
> ( you would not want to do it on invite auths, because it will  
> include GOOD auths for calls )
>
> I still like the idea of loggin sip_authentication timeouts ..
> I might play with that a little today.
>
> J
>
> On Mon, Feb 21, 2011 at 8:28 PM, Spencer Thomason <spencer at 5ninesolutions.com 
> > wrote:
> After tinkering with it, I think that might be the best way.  The
> iptables method is cool but I'd like to have more dynamic control and
> with Fail2Ban looking at the challenges you could specifically ignore
> certain high traffic IPs and block others.  What would be very cool is
> if instead of logging every challenge, a log entry was written if
> there was a high number from a specific IP, then you could decide what
> to do about it with fail2ban, similar to the pike module for opensips
> does.
>
>
> On Feb 21, 2011, at 1:31 AM, covici at ccs.covici.com wrote:
>
> > I would change sip auth failure to challenge and then have  
> sufficient
> > times to only block if there are too many challenges in a certain
> > time.
> > I am not even sure the failure works any more in recent gits.
> >
> > 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
> >
> > --
> > Your life is like a penny.  You're going to lose it.  The question  
> is:
> > How do
> > you spend it?
> >
> >         John Covici
> >         covici at ccs.covici.com
> >
> > _______________________________________________
> > 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/039f39db/attachment-0001.html 