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@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@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@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@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@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