<div dir="ltr"><div>A very simple test.<br><br>nmap -sU -p 4569 --script iax2-brute 192.168.1.19<br><br></div>With delayreject=no:<br><div><br>| iax2-brute: <br>|Â Â Accounts<br>|Â Â Â Â No valid accounts found<br>|Â Â Statistics<br>
|Â Â Â Â Performed 1964 guesses in 7 seconds, average tps: 280<br>|Â Â <br>|_ ERROR: Too many retries, aborted ...<br><br></div><div>With delayreject=yes:<br><br>| iax2-brute: <br>|Â Â Accounts<br>|Â Â Â Â No valid accounts found<br>
|Â Â Statistics<br>|Â Â Â Â Performed 10 guesses in 1 seconds, average tps: 10<br>|Â Â <br>|_ ERROR: Too many retries, aborted ...<br></div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">So, in short, delayreject=yes DOES help to protect against brute force attacks.<br>
</div><div class="gmail_extra"><br><div class="gmail_quote">2013/11/12 Scott Griepentrog <span dir="ltr"><<a href="mailto:sgriepentrog@digium.com" target="_blank">sgriepentrog@digium.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div style="color:rgb(102,0,0)">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.</div>
</div><div class="gmail_extra"><div><div class="h5"><br><br></div></div></div></blockquote></div></div></div></div></div>