[Freeswitch-users] SIP DoS Prevention - Patch

Wed Feb 23 17:08:02 MSK 2011

Keep in mind there is also a register attempt event but this is probably an
ok addition.
On Feb 23, 2011 12:59 AM, "jay binks" <jaybinks at gmail.com> wrote:
> check out my patch Ive just posted to jira.
> http://jira.freeswitch.org/browse/FS-3094
>
> you can subscribe to "Auth" events now - SWITCH_EVENT_AUTH
> which are generic for Register & Invite ( and any other auth'd packet I
> guess )
> and there is an auth_state which will tell you if its an auth fail or a
> expire etc..
> you can get the to_user, to_host, useragent, sip profile and network_ip
>
> Auth Expires also have a Log messages similar to Auth Failures ( fail2ban
> compatible )
>
> PLEASE guys give this some testing. I only banged this together in a few
> hours today in my currently sleep deprived state. So im sure its going to
> have things that can be improved or work better, but at least the bones of
> it are there now.
>
> let me know your thoughts.
>
> Jay
>
>
>
> On Mon, Feb 21, 2011 at 11:08 PM, Jmesquita at freeswitch.org <
> jmesquita at freeswitch.org> wrote:
>
>> Just an idea for the other developers. Wouldn't be cool to have and event
>> thrown by each module that does authentication so that other application
>> modules are able to listen in those events and do whatever with it? Some
>> people might even like to have that running an eel daemon and throw some
>> snmp traps based on that?
>>
>> Just an idea that might be completely ridiculous or might raise some
>> interest. Events are pretty cheap so there wouldn't be a lot of overhead
>> involved.
>>
>> Regards,
>>
>> João Mesquita
>>
>> On 21/02/2011, at 07:28, 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
>>
>> _______________________________________________
>> 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/20110223/79ed39bf/attachment.html