[Freeswitch-users] INVITE DoS Prevention

[jay binks]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110222/d32d702c/attachment.html