[asterisk-dev] chan_iax2: Change delayreject default to on

[Scott Griepentrog]

Does the delayed reply also delay the next auth request from being
processed?  I'm not familiar enough with the protocol to know if
overlapping requests are prevented.  If not, then an attacker simply
ignores all negative responses regardless of delay and looks for a positive
response, negating any benefit by using delayreject.


On Mon, Nov 11, 2013 at 3:49 PM, Mark Michelson <mmichelson at digium.com>wrote:

> On 11/09/2013 05:59 AM, Eugene Varnavsky wrote:
>
>> Hello!
>>
>> Delayreject option means that, if auth is unsuccessful, delay reject
>> answer by 1000 ms.
>> It's off by default.
>>
>> I see no reason to have it off. Only if we want to help bruteforcers.
>>
>> I think default value should be changed to 'on' and I see no drawbacks in
>> this.
>>
>
> I've been giving this a look, and I don't like this idea. Someone with
> more IAX2 knowledge can feel free to correct me about specifics, but in
> general it feels wrong to treat auth rejection replies differently than
> other rejection replies.
>
> If I'm attacking an Asterisk system with a variety of IAX2 messages and I
> start noticing that rejection replies start having a one second delay on
> them, I know that I am triggering chan_iax2's code to check authentication,
> and that is where my attempt is failing. I know now that I am not in
> violation of anything that may have prevented my call from even reaching
> authentication code. Similarly, if my attack attempts initially start by
> receiving rejections with a one second delay, but then they all of a sudden
> don't, that's even worse. It means I have successfully cracked an account
> and password and that there is something much milder that is preventing me
> from making my malicious calls. In either case, if the option is not in
> use, then there is no easy way for me to know why my attacks are failing.
>
> In all, this option feels more like a "security through obscurity" option
> anyway. Good encryption and password selection is better than delaying
> rejection attempts by an extra second.
>
> Just my two cents.
> Mark Michelson
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
[image: Digium logo]
*Scott Griepentrog*
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com <http://www.digium.com> ·
http://asterisk.org <http://www.asterisk.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131111/4e3b9087/attachment-0001.html>