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.
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: ngrep -t -d br0 -q -W single Proxy-Authorization port 5060 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): route add 123.123.123.123 lo && sleep 1 && route del 123.123.123.123 lo Cheers, Kingsley. On Thu, 2020-10-29 at 08:39 +0100, Olivier wrote: > Hi, > What if some fail2ban magic could keep OpenSIPs response from hitting > Asterisk after N attempts ? > > Le mer. 28 oct. 2020 à 18:32, Kingsley Tart - Barritel Ltd < > kingsley.t...@barritel.com> a écrit : > > Hi, > > > > We're using Asterisk 13.17.0 with PJSIP 2.8 bundled. > > > > I've found an issue when Asterisk tries to make a SIP call out > > using > > auth, but has the wrong credentials and keeps getting returned a > > SIP > > 407, in this example to an OpenSIPs server requiring user auth. > > > > Basically this happens: > > > > 1. Asterisk sends plain INVITE to OpenSIPs > > 2. OpenSIPs responds with SIP 407 auth required with a Proxy- > > Authenticate header > > 3. Asterisk re-sends INVITE to OpenSIPs with Proxy-Authorization > > header, but has the wrong password > > 4. goto step 2 and repeat forever > > > > So what we're seeing is Asterisk re-sending an INVITE with > > incorrect > > auth (which is clearly never going to work), about every 2ms. > > > > The Call-ID remains the same all of the time. > > > > Shouldn't PJSIP realise that this isn't going to work after a few > > tries > > and give up? > > > > The only way I've found of stopping the seemingly infinite loop is > > to > > either restart Asterisk or temporarily block network traffic > > between > > the two machines in order to break the cycle. > > > > Any idea whether this has been fixed in a later version? > > > > This is basically the response coming back from OpenSIPs > > (anonymised), > > whether Asterisk didn't provide > > > > SIP/2.0 407 Proxy Authentication Required > > Via: SIP/2.0/UDP > > 100.101.102.103:5060;received=100.101.102.103;rport=5060;branch=z9h > > G4bKPja942e87d-c501-4834-9184-f002c3fd53d2 > > From: <sip:01970123456@100.101.102.103>;tag=075f669f-9115-42a8- > > 8c98-6170a2910e4b > > To: <sip:012345678...@opensips7a.barritel.com>;tag=c97b4d1cb1f3d0da > > 549e06a8d482ef63.fefa > > Call-ID: f79caf90-5b95-4db7-966b-a42e2d372c90 > > CSeq: 34157 INVITE > > Proxy-Authenticate: Digest realm="sip.example.com", > > nonce="5f96c21800011caac9f7e901848de60a1e186b402bd9b710", > > qop="auth" > > Server: OpenSIPS (1.11.6-tls (x86_64/linux)) > > Content-Length: 0 > > > > The caveat is that whether what OpenSIPs is doing is correct or > > broken, > > our customers can edit the auth on their own SIP gateways, so our > > system needs to be able to handle it properly. > > > > Cheers, > > Kingsley. > > > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users