PJSIP Tight Loop On Auth Failure

Home » Asterisk Users » PJSIP Tight Loop On Auth Failure
Asterisk Users 6 Comments

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=z9hG4bKPja942e87d-c501-4834-9184-f002c3fd53d2
From: ;tag=075f669f-9115-42a8-8c98-6170a2910e4b To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.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.

—

6 thoughts on - PJSIP Tight Loop On Auth Failure

  • This is not yet fixed, but is being worked on. I have it as a security issue currently out of caution (although I don’t think we’ll treat it as one after further investigation).

  • Right OK, thanks.

    Do you have any idea of the sort of timescale, and whether it’ll be available as a patch that we can apply to our existing installation?

    We have a very complicated setup and many months of dev time invested in stuff working with the current version, so an entire version update would require us to do lots of extensive testing before rolling it out.

    Cheers, Kingsley.

    —

  • I don’t have a time frame, and we don’t distribute patches themselves except for security issues. A patch can always be downloaded from Gerrit though for reviews[1] or a patch can be retrieved using Git.

    [1] https://gerrit.asterisk.org/

  • 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.tart@barritel.com> a écrit :

  • 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.

  • Hi,

    I felt that fail2ban in this instance was a bit too much of a blunt tool, so I have for now built a workaround by creating a Perl daemon that watches the output of

    ngrep -TT -d $net_if -q -W single Proxy-Authorization port 5060

    where $net_if is the network interface.

    If it sees more than 5 Proxy-Authorization invites with the same Call-
    ID then it blocks the network route for a second.

    I’ve also added a line in the dialplan to put the Asterisk channel name into a custom SIP header, and if this is found in the INVITE then it first connects to the AMI to do a Hangup(38) on that channel, which gives the user a more accurate error.

    Every 20 seconds it purges any stateful data it holds that’s older than
    20 seconds, in order to stop it eating RAM.

    It seems to work quite well.

    Cheers, Kingsley.

    [snip]

    —