Solved Authentication failed for 127.0.0.1

[bobmanuk]

Morning All,

I have an instance where I get regular authentication failed messages every few seconds:

10/29/2020 9:44:27 AM - [CM102001]: Authentication failed for AuthFail Recv Req REGISTER from 127.0.0.1:5080 tid=546720323 Call-ID=289433018-309221903-384239425: REGISTER sip:127.0.0.1:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK-524287-2---546720323;rport=5080 Via: SIP/2.0/UDP [::ffffUBLICIP]:60442;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=sbc.aaea9843 Via: SIP/2.0/UDP 100.64.36.4:57609;branch=z9hG4bK546720323;received=179.43.171.186 Max-Forwards: 68 Record-Route: <sip:[email protected]:5080;user=proxy;uri=sbc.aaea9843> Record-Route: <sip:[email protected]:5060;user=proxy;tnlid=sbc.aaea9843> Contact: <sip:[email protected]:57609> To: <sip:9788@PUBLICIP> From: <sip:9788@PUBLICIP>;tag=1685589077 Call-ID: 289433018-309221903-384239425 CSeq: 2 REGISTER Proxy-Authorization: Digest username="9788",uri="sipUBLICIP",algorithm=MD5,realm="3CXPhoneSystem",nonce="414d53595f9a8efb56:36f4377bd86b72ce06086ca0c56af44f",response="e8def6e549eecd8a1002e68fd36cf4c4" User-Agent: Avaya one-X Deskphone Content-Length: 0 ; Reason: Credentials don't match, check that authorization-ID and password match the ones in extension settings

PUBLICIP = the customers public IP for their office.

any other IP is local or unknown

We see these types of logs on other instances, but the first line usually contains an IP address of the attacker, which then gets blacklisted after 3 attempts. But because this is 127.0.0.1, this just goes on forever.

3CX version is 16.0.6.655, Debian hosted in Google and setup via PBXExpress

Any suggestions?

 

[JohnS_3CX]

Does the extension 9788 still exist?

It sounds like this is a client that was provisioned at some point and has not reprovisioned since.

You can try changing the tunnel password of the PBX as a last resort (but don't forget to update bridges if you have any)

 

[bobmanuk]

Does the extension 9788 still exist?

It sounds like this is a client that was provisioned at some point and has not reprovisioned since.

You can try changing the tunnel password of the PBX as a last resort (but don't forget to update bridges if you have any)

the instance was set up not too long ago (about 3 months) and no, there has never been an extension with that number, and its not always the same extension it tries either.

In fact, a quick glance at the activity log shows the following extensions tried:
2346
602
2981
309
610
324
3651

the system has 4 digit extensions but the attempts also include 3 digits, which have never been used.

We don't have a bridge, only SBC, Should I reconfigure that also?

 

[JohnS_3CX]

Yeah, although even if you dont it should realise it can no longer connect, and it will re-provision itself automatically within a few moments and come back online.

 

[bobmanuk]

Yeah, although even if you dont it should realise it can no longer connect, and it will re-provision itself automatically within a few moments and come back online.

I changed the trunk password, everything seems to have reprovisioned and works (so far as I can tell) and I am still getting the random extension authentications.

 

[JohnS_3CX]

Did you open port 5060 at the SBC site?

 

[bobmanuk]

Did you open port 5060 at the SBC site?

I didn't, no.

 

[JohnS_3CX]

You might want to double-check that just to be on the safe side

 

[bobmanuk]

You might want to double-check that just to be on the safe side

Yeah... good job I did check, as someone opened the ports

 

[JohnS_3CX]

That should answer the mystery then

So at the SBC site you do NOT need to forward any ports. I suggest you remove all of the above immediately and then reboot a phone or two and check that they work correctly.

 

[bobmanuk]

That should answer the mystery then

So at the SBC site you do NOT need to forward any ports. I suggest you remove all of the above immediately and then reboot a phone or two and check that they work correctly.

Done this and yes, phones still work, and yes, the requests have stopped.

I didn't know the ports were open, I certainly didn't open them. Regardless.

Thanks for the help.

 

[JohnS_3CX]

No problem Bob, and I'm glad to hear all is well now.

For anyone else reading this in the future, if you get random attacker invites that contain your SBC in the Record-Route, then check your firewall immediately and ensure no SBC port forwards have been made at the SBC site.

Just keep in mind that the SBC only relies on your firewall allowing outgoing connections, and the rest should be done automatically without any port forwarding.