Concurrent friend/peer SIP connection

Hi,

How can avoid concurrent peer connection? I want one endpoint connection with a single credential.

Is it possible?

Kind regards,

Al

The two modes are user and peer, not friend and peer. Friend is short hand for both peer and user.

They aren’t connections.

Peers don’t use credentials in bound.

You should never need two sip.conf entries for a single remote system, as long as it is not trying to register under multiple names (in which case having it defined as peer can cause problems).

I think it would help if you described the problem that makes you think you need two “connections”.

Hi,

I need to avoid two endpoint devices to connect to the box with the same credential.

Regards,

Al

Give them different credentials!

I still don’t understand what you are trying to do that would even possibly require two sip.conf entries.

I try to avoid fraud. I want to force one endpoint connection with a single credential. Example user name 123456 secret 55555 only one endpoint, only one ata with this credentials one connection to the box.

I am try to avoid concurrent connection with a single credential. I have defined as friends in my table.

Regards,

Al

Are you talking about the specific sort of fraud where a user gives out their credentials to friends and they share an account? Unless you charge a flat rate, surely that just generates more billable traffic?

If you are simply concerned about identify theft, using strong passwords should be enough.

Note that there will not be concurrent connections, and what will actually happen is that the registered end point will keep changing, which cause havoc with outgoing calls, so should be fairly obvious.

What you probably want is to use call limits, but this will not stop registration hopping.

Your subject confused me because it implied there was a peer and friend association at the same time, when I think you actually mean tow users alternating registrations for the same address of record.

Even if you ignored registrations before re-registration was due (which is probably a breach of the protocol), an attacker could hijack the re-registration.

Hi,

Thx for you input. I do have a very secure box running along fail2ban and the application produce strong password store with encryption in the database but, unfortunately I can protect my customer’s computers. I found some asterisk records in the cdr that are missing from my application’s CDR, to me the customer’s computer was hijacked and the credential were compromised.
A few calls were made using the customer’s credentials, fortunately they found out the same day so, I was able to create new credential for the endpoint device.
According with you there is no way to restrict endpoints devices for one connection, one record at the time in asterisk?
Regards,

Al

Just recently I was contemplating a similar subject - viewtopic.php?t=78542
It seems using type=friend makes it easier for fraudsters as they do not need to register and can send their calls from any IP while the legitimate’s user trunk remains registered and can send/receive calls at the same time.
I never really understood why people use type=friend and have troubles coming with a scenario where it actually would be necessary …

You can limit the number of calls, but that doesn’t help unless the legitimate subscriber has exactly that number of calls in progress most of the time.

The number of registrations is always limited to one. The problem I think you have is that the registration is rapidly switching between two subscribers, only one of which is registered at any one time.

Avoiding host=dynamic will work well, but assumes your customers have static addresses.

The risk of friend and user tends to fall mainly on customer type systems - where it allows account name guessing. You should certainly encourage your Asterisk using customers to only use type=peer. Your address really should be static.

Thx,
A user reported that a few call were not made from his device. I verified asterisk CDR against a2billing records and found the following.

“7783067274”,“7783067274”,“13478606163”,“a2billing”,"""[color=#BF0000]Anonymous"" <7783067274[/color]>",“SIP/7783067274-08716400”,"",“DeadAGI”,“a2billing.php”,“2011-06-09 20:46:14”,“2011-06-09 20:46:14”,“2011-06-09 20:46:16”,2,2,“ANSWERED”,“BILLING”,“asterisk-1307652374.64”,""
“7783067274”,“7783067274”,“13478606163”,“a2billing”,"""[color=#BF0000]Anonymous"" <7783067274[/color]>",“SIP/7783067274-08716400”,"",“DeadAGI”,“a2billing.php”,“2011-06-09 20:46:34”,“2011-06-09 20:46:34”,“2011-06-09 20:46:36”,2,2,“ANSWERED”,“BILLING”,“asterisk-1307652394.65”,""

The user assures me that the device stays on her desk all the time. There is no time between both records to have a device and connected it to some place else. Unfortunately I the CDR did not record the IP connecting from.
I can not avoid host=dynamic, because the user does not have static addresses. I do have static ip also I do have a very secure box including fail2band so, credential guessing is not option one fail and is anned for 24 hours.
Is this the case somebody hack into user account and made calls, if so is a way to prevent two endpoint login to the box with the same credentials?

Regards,

Al

Having looked at the code, that is because you are declaring them as a friend (i.e. both user and peer), rather than as a pure peer. That means that INVITE’s can be matched on user name. That means that every call is matched to a sip.conf entry and authenticated independently, so there is no concept of a connection in the sense that you are using it (a registration against a single peer).

Note that one common problem people have is with trying to have multiple accounts on a single service provider machine. If you configure them as pure peers, you will not be able to distinguish calls made on the different accounts.

WIth a pure peer, an attacker can still hijack the registration, but the legitimate user will be locked out until they re-register in the normal course of events.

This might be true if you are a service provider although not sure if this is the case at hand. I doubt there are multiple accounts on the same IP/port combo.

If you are a subscriber you can have multiple accounts with the same provider as most providers challenge INVITEs. If you have multiple peers with the same IP you can have them defined as type=peer and the correct credentials will be used when responding to the challenge for the INVITE.

For subscriber, the problem with multiple peers on the same IP are incoming calls. Asterisk will accept them on the first IP/port match, so you need to extract some more info from the incoming call in order to figure out which account the call was sent to. It would definitely help if asterisk allowed using more than one port for SIP.