<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Nice idea but I think fail2ban is a bit too much of a blunt tool for this. What's more, I think fail2ban works by following logs and nothing gets logged here. You'd have to do an ngrep or tcpdump really. I suppose fail2ban could be configured to parse the output format.</div><div><br></div><div>All it needs is the network blocked for about 1 second, so what I'll probably do is have a daemon tail output from this command:</div><div><br></div><div>ngrep -t -d br0 -q -W single Proxy-Authorization port 5060</div><div><br></div><div>and if it sees multiple auth invites sent with the same Call-ID then just knobble that route for literally a second or so. PJSIP then hangs up that channel with a 404 pretty quickly, so I've found if I do this (example for remote host on 123.123.123.123):</div><div><br></div><div>route add 123.123.123.123 lo && sleep 1 && route del 123.123.123.123 lo</div><div><br></div><div>Cheers,</div><div>Kingsley.</div><div><br></div><div>On Thu, 2020-10-29 at 08:39 +0100, Olivier wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi,</div><div>What if some fail2ban magic could keep OpenSIPs response from hitting Asterisk after N attempts ?</div><div><br></div><div>Le mer. 28 oct. 2020 à 18:32, Kingsley Tart - Barritel Ltd <<a href="mailto:kingsley.tart@barritel.com">kingsley.tart@barritel.com</a>> a écrit :</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi,</div><div><br></div><div>We're using Asterisk 13.17.0 with PJSIP 2.8 bundled.</div><div><br></div><div>I've found an issue when Asterisk tries to make a SIP call out using</div><div>auth, but has the wrong credentials and keeps getting returned a SIP</div><div>407, in this example to an OpenSIPs server requiring user auth.</div><div><br></div><div>Basically this happens:</div><div><br></div><div>   1. Asterisk sends plain INVITE to OpenSIPs</div><div>   2. OpenSIPs responds with SIP 407 auth required with a Proxy-</div><div>      Authenticate header</div><div>   3. Asterisk re-sends INVITE to OpenSIPs with Proxy-Authorization</div><div>      header, but has the wrong password</div><div>   4. goto step 2 and repeat forever</div><div><br></div><div>So what we're seeing is Asterisk re-sending an INVITE with incorrect</div><div>auth (which is clearly never going to work), about every 2ms.</div><div><br></div><div>The Call-ID remains the same all of the time.</div><div><br></div><div>Shouldn't PJSIP realise that this isn't going to work after a few tries</div><div>and give up?</div><div><br></div><div>The only way I've found of stopping the seemingly infinite loop is to</div><div>either restart Asterisk or temporarily block network traffic between</div><div>the two machines in order to break the cycle.</div><div><br></div><div>Any idea whether this has been fixed in a later version?</div><div><br></div><div>This is basically the response coming back from OpenSIPs (anonymised),</div><div>whether Asterisk didn't provide </div><div><br></div><div>SIP/2.0 407 Proxy Authentication Required</div><div>Via: SIP/2.0/UDP 100.101.102.103:5060;received=100.101.102.103;rport=5060;branch=z9hG4bKPja942e87d-c501-4834-9184-f002c3fd53d2</div><div>From: <sip:<a href="mailto:01970123456@100.101.102.103">01970123456@100.101.102.103</a>>;tag=075f669f-9115-42a8-8c98-6170a2910e4b</div><div>To: <sip:<a href="mailto:012345678900@opensips7a.barritel.com">012345678900@opensips7a.barritel.com</a>>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.fefa</div><div>Call-ID: f79caf90-5b95-4db7-966b-a42e2d372c90</div><div>CSeq: 34157 INVITE</div><div>Proxy-Authenticate: Digest realm="sip.example.com", nonce="5f96c21800011caac9f7e901848de60a1e186b402bd9b710", qop="auth"</div><div>Server: OpenSIPS (1.11.6-tls (x86_64/linux))</div><div>Content-Length: 0</div><div><br></div><div>The caveat is that whether what OpenSIPs is doing is correct or broken,</div><div>our customers can edit the auth on their own SIP gateways, so our</div><div>system needs to be able to handle it properly.</div><div><br></div><div>Cheers,</div><div>Kingsley.</div><div><br></div><div><br></div></blockquote></blockquote></body></html>