PJSIP endpoint identify does not block INVITE from ip address that don't match

Asterisk Asterisk Support
1

Hi,

I have a security problem with PJSIP channel.

I configured a trunk identified by IP.

With ‘show endpoints’ I can see that match correctely the ip address and no ‘auth’ are used.

When I try to do a INVITE session from another IP address than matched but with the same name of endpoints, the session is authorized and not rejected.

Did I make a configuration error or is it a big security issue?

This is Asterisk 13.13 but I try Asterisk 14 and is the same.

Thanks for your reply.

Best regards.

Stefano

The config:

[105011001]
type=aor
contact=sip:212.97.59.76

[105011001]
type=endpoint
context=user
disallow=all
allow=ulaw
aors=105011001

[105011001]
type=identify
endpoint=105011001
match=212.97.59.76/32

This is show endpoints:

Endpoint: 105011001 Not in use 0 of inf
Aor: 105011001 0
Contact: 105011001/sip:212.97.59.76 b41d8ed5f0 Created 0.000
Identify: 105011001/105011001
Match: 212.97.59.76/32

And This the SIP Messages:

PJSIP Logging enabled
<— Received SIP request (816 bytes) from UDP:93.70.14.88:45020 —>
INVITE sip:999@78.47.227.81:6000;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.9.0.25:45020;branch=z9hG4bK-524287-1—d1443119d97b8c0a;rport
Max-Forwards: 70
Contact: sip:105011001@10.9.0.25:45020;transport=UDP
To: sip:999@78.47.227.81:6000;transport=UDP
From: sip:105011001@78.47.227.81:6000;transport=UDP;tag=7b678358
Call-ID: EHDlM8–H9t9R0NAbFDMbw…
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rd82a609
Allow-Events: presence, kpml, talk
Content-Length: 235

v=0
o=Zoiper 0 0 IN IP4 10.9.0.25
s=Zoiper
c=IN IP4 10.9.0.25
t=0 0
m=audio 62332 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

<— Transmitting SIP response (324 bytes) to UDP:93.70.14.88:45020 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.9.0.25:45020;rport=45020;received=93.70.14.88;branch=z9hG4bK-524287-1—d1443119d97b8c0a
Call-ID: EHDlM8–H9t9R0NAbFDMbw…
From: sip:105011001@78.47.227.81;tag=7b678358
To: sip:999@78.47.227.81
CSeq: 1 INVITE
Server: Asterisk PBX certified/13.13-cert4
Content-Length: 0

<— Transmitting SIP response (807 bytes) to UDP:93.70.14.88:45020 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.9.0.25:45020;rport=45020;received=93.70.14.88;branch=z9hG4bK-524287-1—d1443119d97b8c0a
Call-ID: EHDlM8–H9t9R0NAbFDMbw…
From: sip:105011001@78.47.227.81;tag=7b678358
To: sip:999@78.47.227.81;tag=32dd72e9-52a5-4a31-9d13-9cf62681fd98
CSeq: 1 INVITE
Server: Asterisk PBX certified/13.13-cert4
Contact: sip:78.47.227.81:6000
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 219

v=0
o=- 0 2 IN IP4 172.31.1.100
s=Asterisk
c=IN IP4 78.47.227.81
t=0 0
m=audio 18056 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<— Received SIP request (408 bytes) from UDP:93.70.14.88:45020 —>
ACK sip:78.47.227.81:6000 SIP/2.0
Via: SIP/2.0/UDP 10.9.0.25:45020;branch=z9hG4bK-524287-1—97ee6aeb49fe1070;rport
Max-Forwards: 70
Contact: sip:105011001@10.9.0.25:45020;transport=UDP
To: sip:999@78.47.227.81;tag=32dd72e9-52a5-4a31-9d13-9cf62681fd98
From: sip:105011001@78.47.227.81;tag=7b678358
Call-ID: EHDlM8–H9t9R0NAbFDMbw…
CSeq: 1 ACK
User-Agent: Zoiper rd82a609
Content-Length: 0

2

This is how it works by default, the user portion of the From is also used for determining which endpoint the call is in regards to. If you don’t want to do that you can try using “identify_by=auth_username” which since the endpoint would never auth shouldn’t allow it to be matched based on username. I haven’t tested that scenario, though.

1 Like
3

Thanks for your reply.

I tried to add ‘identify_by=auth_username’, but the INVITE session from different ip address than matched isn’t rejected.

Effectively, compared to before, the answer to the first INVITE message was ‘401 Unauthorized’ and this is correct but when the remote endpoint send authentication, (nothing is configured about authentication on Asterisk for this endpoint) Asterisk connect the endpoint !!!

This because in the second INVITE message with authentication is filled authentication username with the name of endpoint.

I have the impression that the identification by match ip address does not work and bypass all connection that have the correct name.

I’had installed Asterisk 14 with pjsip bundled and after I have installed pjsip separately before install Asterisk 13 certified and in both case I found the same actions.

I found on https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships

this statement I can not understand well:
…
IDENTIFY
(provided by module: res_pjsip_endpoint_identifier_ip)
Controls how the res_pjsip_endpoint_identifier_ip module determines what endpoint an incoming packet is from. If you don’t have an identify section defined, or else you have res_pjsip_endpoint_identifier_ip loading after res_pjsip_endpoint_identifier_user, then res_pjsip_endpoint_identifier_user will identify inbound traffic by pulling the user from the “From:” SIP header in the packet. Basically the module load order, and your configuration will both determine whether you identify by IP or by user.
…

You have ideas about it ???

Thanks and best regards.

Stefano

The changed config:

[105011001]
type=endpoint
context=user
identify_by=auth_username
disallow=all
allow=ulaw
aors=105011001

The SIP messages:

CentOS-73-64-minimal*CLI>
<— Received SIP request (816 bytes) from UDP:93.70.14.88:45020 —>
INVITE sip:999@78.47.227.81:6000;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.9.0.25:45020;branch=z9hG4bK-524287-1—19cb4b87caedbd5a;rport
Max-Forwards: 70
Contact: sip:105011001@10.9.0.25:45020;transport=UDP
To: sip:999@78.47.227.81:6000;transport=UDP
From: sip:105011001@78.47.227.81:6000;transport=UDP;tag=ada15154
Call-ID: V76oeR9k7dJumlKF2YE3bw…
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rd82a609
Allow-Events: presence, kpml, talk
Content-Length: 235

v=0
o=Zoiper 0 0 IN IP4 10.9.0.25
s=Zoiper
c=IN IP4 10.9.0.25
t=0 0
m=audio 62332 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

[Aug 15 23:11:42] NOTICE[14928]: res_pjsip/pjsip_distributor.c:508 log_failed_request: Request ‘INVITE’ from ‘sip:105011001@78.47.227.81’ failed for ‘93.70.14.88:45020’ (callid: V76oeR9k7dJumlKF2YE3bw…) - No matching endpoint found

<— Transmitting SIP response (517 bytes) to UDP:93.70.14.88:45020 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.9.0.25:45020;rport=45020;received=93.70.14.88;branch=z9hG4bK-524287-1—19cb4b87caedbd5a
Call-ID: V76oeR9k7dJumlKF2YE3bw…
From: sip:105011001@78.47.227.81;tag=ada15154
To: sip:999@78.47.227.81;tag=z9hG4bK-524287-1—19cb4b87caedbd5a
CSeq: 1 INVITE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1502831502/7fe9b67df3722678f83e1e6f58faf8e4”,opaque=“38808cf3140dc9ce”,algorithm=md5,qop=“auth”
Server: Asterisk PBX certified/13.13-cert4
Content-Length: 0

<— Received SIP request (359 bytes) from UDP:93.70.14.88:45020 —>
ACK sip:999@78.47.227.81:6000;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.9.0.25:45020;branch=z9hG4bK-524287-1—19cb4b87caedbd5a;rport
Max-Forwards: 70
To: sip:999@78.47.227.81;tag=z9hG4bK-524287-1—19cb4b87caedbd5a
From: sip:105011001@78.47.227.81:6000;transport=UDP;tag=ada15154
Call-ID: V76oeR9k7dJumlKF2YE3bw…
CSeq: 1 ACK
Content-Length: 0

<— Received SIP request (1122 bytes) from UDP:93.70.14.88:45020 —>
INVITE sip:999@78.47.227.81:6000;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.9.0.25:45020;branch=z9hG4bK-524287-1—8dd7ccc2af528dae;rport
Max-Forwards: 70
Contact: sip:105011001@10.9.0.25:45020;transport=UDP
To: sip:999@78.47.227.81:6000;transport=UDP
From: sip:105011001@78.47.227.81:6000;transport=UDP;tag=ada15154
Call-ID: V76oeR9k7dJumlKF2YE3bw…
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rd82a609
Authorization: Digest username=“105011001”,realm=“asterisk”,nonce=“1502831502/7fe9b67df3722678f83e1e6f58faf8e4”,uri=“sip:999@78.47.227.81:6000;transport=UDP”,response=“c4b8430211c7d6168cb05767e597d338”,cnonce=“2de479d81dff0283a5aabf7e30712847”,nc=00000001,qop=auth,algorithm=md5,opaque=“38808cf3140dc9ce”
Allow-Events: presence, kpml, talk
Content-Length: 235

v=0
o=Zoiper 0 0 IN IP4 10.9.0.25
s=Zoiper
c=IN IP4 10.9.0.25
t=0 0
m=audio 62332 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

<— Transmitting SIP response (324 bytes) to UDP:93.70.14.88:45020 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.9.0.25:45020;rport=45020;received=93.70.14.88;branch=z9hG4bK-524287-1—8dd7ccc2af528dae
Call-ID: V76oeR9k7dJumlKF2YE3bw…
From: sip:105011001@78.47.227.81;tag=ada15154
To: sip:999@78.47.227.81
CSeq: 2 INVITE
Server: Asterisk PBX certified/13.13-cert4
Content-Length: 0

4

That option was a long shot. The statement is old but correct, the user portion of the From is used to find the endpoint. If it matches an endpoint, it’ll be used. You can also use the “permit” and “deny” options to only allow a specific IP address/range to be allowed to use the endpoint.

5

I had already thought this solutions of acl but the acl is active for the server, not for single endpoint.

I tried to load only the module for ip authentication and it works correctly, the INVITE message is rejected 401

When later also loads the user authentication module, the ip authentication stops working.

The module for authentication with user is prevalent on ip address matching.

In other words this means that the only way to authenticate an endpoint is through username and password.

I found dangerous that this issue is not said, I found casually this issue.otherwise I will configure all endpoit by address identify and worldwide can use my endpoints simply guessing the username !!!

All configuration samples speak that is possible to do authentication by matching ip address and not sayd that this does not work.

A this point with pjsip is not possible use endpoint with ip address authentication!!

Thanks for your help.

Best regards.

Stefano

6

IP based matching isn’t really used for authentication and is used by most individuals with their ITSPs, which go to a context that is limited in what can be dialed. If there’s documentation on the wiki we can improve to make this more clear please comment on the page that would have helped.

7

I too experienced this issue, as a suggestion, would it not be a good idea to set the authentication type for an endpoint (i.e. match type)? I.e. user match or IP match? It would remove ambiguity and help improve security?

Just a thought…

8

The identify_by option could be extended to do that, yes.

1 Like
9

OK, if in the wiki or samples conf you read that this feature don’t works then you can do somethings for workaround.

There are thousands of people who setting up their Asterisk and no one tells you that this features is a security risk.

You can not know in what way people configure their own Asterisk.

I personally have about 10 ITPs configured with IP Address based authentication and come in the same user context.

Certainly now that I know I will do something different.

This is precisely the case, if a feature does not work because it does not say it and creates security risks?

10

Thanks for your reply.

Personally I have one my ITSP that accept user autentication (my authentication to him) for outbound call but for incoming call I must authenticate him by Ip Address.

There aren’t ambiguity, you can authenticate by IP Address or by Username e Password, Where is ambiguity?

There are two module in PJSIP for this reason, Wiki and samples conf of PJSIP sayd that is possible authenticate by IP ADDRESS or by Username.

I just discovered that the module for ip authentication works well only if the module for user authentication isn’t loaded.

For me this is simply a issue and this certainly not improve security.

11

I’m not familiar with chan_pjsip, but one of the pieces of security advice for chan_sip is to use type=peer, precisely because it can’t be spoofed by someone who knows the user and password, unless they can also fake the IP address.

12

In PJSIP that is referred to as endpoint matching. Given an incoming request match it against a configured endpoint. The order in which this happens is configurable in pjsip.conf using the endpoint_identifier_order option in the global section. This same process happened in chan_sip but was not configurable. Authentication is separate. In your scenario you’d like to limit this endpoint matching to only IP for certain things, I think this is reasonable and you can file an issue on the issue tracker[1]. As for your comment about it not working when the user module is loaded - the latest versions should have a default of “ip,username,anonymous” which prefers IP first over username.

[1] https://issues.asterisk.org/jira

13

Thanks for your intervention.

Best regards.