Type=friend is bad for you

Just browsing through “Asterisk™: The Definitive Guide” - ofps.oreilly.com/titles/9780596517342/ uncovers number of places where the authors suggest using type=friend for SIP device definition.

This is a very strange proposition. I asked multiple times for an example where type=friend would be necessary, e.g. viewtopic.php?t=78679 and have not seen an answer.

The problem with type=friend is it creates peer as well as user. The user part allows bruteforcing accounts in a way that fail2ban can not protect against. It also allows calls without registration.

Do yourself a favor and change all of your type=friend to type=peer. The output from

should be empty.

Another little known fact about the difference between peer and friend:
Friend will challenge INVITEs. When making outbound calls from a registered phone/peer another challenge will be issued.

This means type=friend requires second INVITE with authentication credentials, while peer will accept INVITE without challenge.

In other words type=friend does not care about the phone registration status and always tries to authenticate as if the phone never registered.

This is probably a good time for digium to clarify when type=friend should be used.
I did some testing after sysadminman released FreePBX security advisory:
sysadminman.net/blog/2011/freepb … types-2795

The short version is it is confusing as hell. I was able to make calls w/o registration even if device was defined as type=peer.
DIgium: if you can find anyone who can still remember how different sip types were supposed to be used, please share this knowledge with your users.

There definitely seems to be some confusion about this.

I read quite a lot of posts before writing on my blog, and I’m still a little confused. Obviously the best thing is to restrict what IPs can connect over the SIP port. However, not everyone either can, or does, do this and any advice that can be offered to people to make their systems as secure as possible is great.

Any clarification or guidance would definitely be appreciated.

Discovered a case where type=friend is necessary:
32 port FXS gateway using a single udp port - D-Link DVG-2032 -

The other occasion when type=friend is easiest option is where the SIP devices all have the same IP address. For example, I have 4 DECT handsets off a Siemens Gigaset base station which is registered on the network as 192.162.XXX.XXX. If I set the type=peer, I get failed calls because of a username mismatch, because the username the handset sends does not match the digest from the IP address (which appears to be the first user in SIP conf which matches the IP address).

I have tried playing with changes to the port number for the individual devices to attempt to get round the problem, but it did not work. The only way I can get these DECT handsets to register on the server is to use type=friend. I imagine that the same will apply to a number of ATAs.

If you have other ideas, I would be pleased to try them. At the moment I block external SIP connections at the firewall anyway but it would be good to have another layer of security in the event that I do need to open up the server to external SIP connections.


Yep I agree with the 2 above, we have seen this issue with snom m3 and m9. Only work properly when set to friend

twitter @cyberco

[quote=“jay272bea”]The other occasion when type=friend is easiest option is where the SIP devices all have the same IP address.
The same IP address is not a problem. Just like DVG-2032 the problem here is the same port.

Actually, no. Linksys ATAs use different ports for each line and can be used with type=peer just fine.
The problem is when you have two SIP endpoints and each one is only using one port.
It would not be a problem if asterisk could use more than one SIP port. This would also solve other issues, like registering multiple accounts with the same provider.