[Freeswitch-users] INVITE DoS Prevention

Tue Feb 22 03:06:00 MSK 2011

maybe put your logs on TmpFS also then ?
I assume you have your DB on TmpFS already ?

Jay

On Tue, Feb 22, 2011 at 8:55 AM, Spencer Thomason <
spencer at 5ninesolutions.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/14a4b80f/attachment.html 