Stopping Rogue SIP peers from Registering

Very rarely, about once every six months, we have a case of toll fraud to investigate. And the reason is somehow a remote peer’s session is taken over by a rogue actor with a foreign IP address.

We have various remote phones that register with our asterisk box. Many have dynamic IP addresses, which makes it difficult to lock things down by IP address, so our system is setup to accept registrations from any ip address.

HTTP and HTTPS access is locked down to 5 authorized IP addresses that admins will login from.

We use strong passwords. All our passwords are 25 random letters and numbers.

Versions are as follows:
Asterisk 11.25.1
FreePBX 12.0.76.4

Here’s the log entries from the most recent case:

[2017-10-15 02:27:14] VERBOSE[1880] chan_sip.c: – Registered SIP ‘21’ at 2.2.2.2:6289
[2017-10-15 02:51:23] NOTICE[1880] chan_sip.c: Peer ‘21’ is now UNREACHABLE! Last qualify: 193
[2017-10-15 02:52:06] NOTICE[1880] chan_sip.c: Peer ‘21’ is now Reachable. (1191ms / 2000ms)
[2017-10-15 02:52:07] VERBOSE[1880] chan_sip.c: – Unregistered SIP ‘21’
[2017-10-15 02:52:17] VERBOSE[1880] chan_sip.c: – Registered SIP ‘21’ at 2.2.2.2:6288
[2017-10-15 03:00:27] VERBOSE[1880] chan_sip.c: – Registered SIP ‘21’ at 1.1.1.1:5062
[2017-10-15 03:35:35] VERBOSE[1880] chan_sip.c: – Unregistered SIP ‘21’
[2017-10-15 05:48:40] VERBOSE[1880] chan_sip.c: – Registered SIP ‘21’ at 3.3.3.3:15576
[2017-10-15 06:17:52] NOTICE[1880] chan_sip.c: Peer ‘21’ is now UNREACHABLE! Last qualify: 798
[2017-10-15 06:20:31] VERBOSE[1880] chan_sip.c: – Registered SIP ‘21’ at 1.1.1.1:5062
[2017-10-15 06:20:31] NOTICE[1880] chan_sip.c: Peer ‘21’ is now Reachable. (72ms / 2000ms)
[2017-10-15 07:10:33] VERBOSE[3969] chan_sip.c: – Registered SIP ‘21’ at 1.1.1.1:5062
[2017-10-15 07:36:48] VERBOSE[3969] chan_sip.c: – Registered SIP ‘21’ at 3.3.3.3:10595
[2017-10-15 08:00:34] VERBOSE[3969] chan_sip.c: – Registered SIP ‘21’ at 1.1.1.1:5062
[2017-10-15 08:33:53] VERBOSE[3969] chan_sip.c: – Registered SIP ‘21’ at 3.3.3.3:17475
[2017-10-15 08:50:35] VERBOSE[3969] chan_sip.c: – Registered SIP ‘21’ at 142.161.140.120:5062

I have renamed the IP addresses as follows:
1.1.1.1 - this is a dynamic IP from our ISP that is from the remote employee
2.2.2.2 - this is the first rogue IP address
3.3.3.3 - this is a second rogue IP address

According to the logs, at 2:27am the rogue IP 2.2.2.2 registered itself. Prior to that, the expected IP of 1.1.1.1 was live with this. Normally when there is an IP change I see a pair of messages in the log. First “Peer XX is now reachable” and then this line recording the new IP address.

Is it possible for Asterisk to accept a new IP address for an existing SIP session? And to do this without asking the peer to re-register?

With chan_sip, whatever IP address a peer has registered from last, that’s the one Asterisk considers to be active. The old one is dropped.

Now the question is what are those rogue IP addresses that your peers register from.
Normally with port 5060 open and strong passwords, you should see random attempts, with random extensions and passwords being tried and mostly failed attempts, with fail2ban jumping in.

It’s unlikely someone would guess a 25 digit password at first attempt.

Do you see any failed attempts too (wrong passwords being tried)?
Are you sure those registrations aren’t legitimate ones?
Are any unwanted calls initiated from extension 21?

Yes, I do see about 5,000 “Wrong password” entries in log over the last 5 days. Various random extensions, but nothing for extension 21 which was the one compromised.

One particular attempt was on extension 1199. There was 68 attempts from 23:34 to 23:45. So a 11 minute window and then fail2ban kicked in. Seems rather long to allow attempts.

When I look up the IP address, it belongs to a country in Europe. They are definitely NOT legitimate.
Yes, there are unwanted long distance calls on 21. We don’t have much cash in the account, so when they drained it to zero, the calls started to fail, and then they stopped.

I would suspect that your extension 21 itself has been compromised, many have an available service with a “well known password” than can leek stuff

Leaving port 5060 open to the internet at large is a risky thing to do for sure, as you have seen, but you can take a few measures to reduce the risk of toll fraud. Such as:

  • Add alwaysauthreject = yes to your chan_sip settings. Setting this to “yes” will reject bad authentication requests on valid usernames with the same rejection information as with invalid usernames, denying remote attackers the ability to detect existing extensions with brute-force guessing attacks. In other words, the attacker doesn’t know if his attempt was denied because of a bad password or a non existing extension.

  • Use the permit/deny options under device options for each extension that is not remote, but local. Allow only registrations from your private subnet on those. Then at least your local extensions can’t be used to make fraudulent calls.

  • Change your SIP port to something other than standard 5060 for your remote extensions

  • Your fail2ban isn’t working as it should, make it work

More secure, but more cumbersome is to install DDNS clients on your remote users’ devices and instead of keeping SIP port 5060 open to everyone, allow traffic from known FQDNs. The DDNS clients update the domain name with the clients new IP address whenever it changes.

1 Like