Sip.conf Security Help

Hello

Hopefully someone can help Ive had an asterisk 1.8.8.1 box running for a while and recently had a requirement to configure an offsite sip phone.

ive opened port 5060 to the world because unfortunatly the end user is a dynamic IP, i use strong password on the extension I have configured and all is working well. i have configured fail2ban to reduce bruteforce success … hopefully. the problem I have is that previously traffic to port 5060 was restricted to/from our voip provider now this restriction has been removed i am receiving call attempts into the general context. fortunatly there isnt an extension configured for outbound calling and all calls our routed to our inbound service but the attempts are annoying my and i want to remove them from our logs.

in the ideal world all inbound calls are restricted to our voip provider but handsets can attempt to connect from any where i understand the risk but with secure passwords (12 character upper lower and symbols) and fail2ban to minimise attempts i presume thats a safe way to be…

can i create an inbound sip.conf configuration from our provider and then the extensions that can be connected to through auth?

currently our inbound is not configured for authentication i would need to contact our provider to see if this is an option.

sip.conf

[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
localnet=xx.110.2x.0/255.255.255.0
localnet=xx.110.2x.0/255.255.255.0
externip=xx.248.xx.84
deny=0.0.0.0/0
permit=x.145.x.1/24
permit=x.145.x.1/24
permit=x.145.x.1/24
permit=x.145.x.1/24
permit=x.11.x.160/24

[100]
alwaysauthreject=yes
type=friend
username=100
secret=SUPER DUPER PASSWORD
host=dynamic
context=internal
dtmfmode=rfc2833
nat=yes
qualify=yes

[200]
alwaysauthreject=yes
type=friend
username=200
secret=SUPER DUPER PASSWORD
host=dynamic
context=internal
dtmfmode=rfc2833
nat=yes
qualify=yes

[PROVIDEROUT]
context=default
type=peer
host=sipPROVIDER.com
disallow=all
allow=gsm
allow=ulaw
allow=alaw
qualify=20000
canreinvite=no

[PROVIDERIN]
context=default
type=user
host=sip.PROVIDER.com
disallow=all
allow=gsm
allow=ulaw
allow=alaw
qualify=20000
nat=yes
insecure=invite
dtmfmode=rfc2833
rfc2833compensate=no
canreinvite=no
deny=0.0.0.0/0
permit=x.x.191.1/24
permit=x.145.x.1/24

i have included the above because what ever im doing currently doesnt seem to help …

any advice would be greatly appreciated

The “extension” device entries should be type=peer.

Their names should not be predictable (e.g. MAC addreses).

allowguest needs to be turned off.

alwaysauthreject is only meaningful in the general section (and of limited use without fixing allowguest).

If you have to use insecure=invite, you might as well have one section for both directions and use type=peer, for it. I’m not entirely sure which entry will actually be used if only the IP address matches, anyway.

Non-security:

Is your ISP really inside NAT and your Asterisk outside? Same for the “extensions”? nat=yes only applies to those situations, not to the normal NAT case where Asterisk and the extensions are inside and the ITSP is outside.

“canreinvite” is deprecated. You should replace it with “directmedia”.

The first xx in the local net values pretty much has to be 10, so I’m not sure why you have suppressed it.

x.11.x.160/24 is an invalid IPv4 network pattern. The 160 must be a zero. Similarly for x.145.x.1/24.

I can’t work out the difference between the two sip.conf’s.

i have spoken to my sip provider to try and understand how to register with them, and i received this responce

If the above is for inbound SIP registration, the entries should be against sip.PROVIDER.com rather than sip-border or sip-wholesale. sip.PROVIDER.com is the only SIP registration platform we offer.

so i have configured my sip.conf as follows

[general]
allowguest=off
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
localnet=10.110.205.0/255.255.255.0
localnet=10.110.201.0/255.255.255.0
externip=x.248.x.84
register => 699:65@sip.PROVIDER.com/699
register => 698:69@sip.PROVIDER.com/698

and configured the peers

[0178111111]
context=default
type=peer
username=699
secret=65
host=sip.PROVIDER.com
disallow=all
allow=gsm
allow=ulaw
allow=alaw
qualify=20000
insecure=invite
dtmfmode=rfc2833
rfc2833compensate=no
canreinvite=no
deny=0.0.0.0/0
permit=x.145.x.0/24
permit=x.145.x.0/24
permit=x.145.x.0/24
permit=x.145.x.0/24

[0178222222]
context=default
type=peer
username=698
secret=69
host=sip.PROVIDER.com
disallow=all
allow=gsm
allow=ulaw
allow=alaw
qualify=20000
insecure=invite
dtmfmode=rfc2833
rfc2833compensate=no
canreinvite=no
deny=0.0.0.0/0
permit=x.145.x.0/24
permit=x.145.x.0/24
permit=x.145.x.0/24
permit=x.145.x.0/24

and i still receive the error

chan_sip.c:22041 handle_request_invite: Sending fake auth rejection for device sip:01782111111@x.145.x.131;tag=8S8P051IJW30000E1D00001u0VJCX2B1041JZV

any advice would be great

You seem to have two peers with the same IP address. Asterisk cannot tell them apart.

I assume that PROVIDER is a metaname, as there is a provider.com, but no sip.provider.com.

There is no need for permit and deny a static address, as only that single address will match. I suspect that sip..com is not a valid source address for the provider, in which case you do need to use a user type entry, which will mean that they have to provide their identity in the From header, rather than the CLID, or you have to use allowguest and deny/allow, and handle the call in the default context.

From the error message, it does look as though they may be using the From address as the account name, rather than as CLID. In that case, you will have to see if they are sending the CLID by some other means, and enable that mechanism in the sip.conf entry.

Seeing the full invite request may clarify what they are doing.

In your original configuration, host was bogus for the user entry, as user entries do not match on IP address (and you had malformed network masks).

I don’t think your provider is Asterisk friendly!

Hi David my inbound calls are from the same provider i presumed i would need to configure each seperatly. the provider is AQL, host is sip.aql.com but the ip that resolves to is differant than the address i receive the calls from.

to show you the full invite request do i paste the contents of sip show debug on ?

Yes. In this case, just the INVITE request should do. However, people often miss the first few lines, so it might be safer to start earlier than you think.

Hi David

not sure if this will help but i think its what you asked for

[2012-11-09 17:47:07] NOTICE[1366]: chan_sip.c:22041 handle_request_invite: Sending fake auth rejection for device sip:0178111111@194.145.191.131;tag=8S8P051IJW30000E1D00001u0WOSOBS04X6SH8

<— Reliably Transmitting (NAT) to 212.11.94.169:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 212.11.94.169;branch=z9hG4bK5f8b.63368a25.0;received=212.11.94.169;rport=5060
Via: SIP/2.0/UDP 194.145.191.131:5060;branch=z9hG4bK000423E166BE984288811782D421
From: sip:01782111111@194.145.191.131;tag=8S8P051IJW30000E1D00001u0WOSOBS04X6SH8
To: sip:44178222222@212.11.94.169;tag=as6864f048
Call-ID: bee104006623-509d419b-1cd0996d-b65d0f0-81e059c@127.0.0.1
CSeq: 32635 INVITE
Server: Asterisk PBX 1.8.8.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="2022d71c"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘bee104006623-509d419b-1cd0996d-b65d0f0-81e059c@127.0.0.1’ in 32000 ms (Method: INVITE)
Scheduling destruction of SIP dialog ‘bee104006623-509d419b-1cd0996d-b65d0f0-81e059c@127.0.0.1’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:212.11.94.169:5060 —>
ACK sip:441789510254@x.248.x.84 SIP/2.0
Via: SIP/2.0/UDP 212.11.94.169;branch=z9hG4bK5f8b.63368a25.0
From: sip:01782111111@194.145.191.131;tag=8S8P051IJW30000E1D00001u0WOSOBS04X6SH8
Call-ID: bee104006623-509d419b-1cd0996d-b65d0f0-81e059c@127.0.0.1
To: sip:44178222222@212.11.94.169;tag=as6864f048
CSeq: 32635 ACK
Max-Forwards: 70
User-Agent: OpenSIPS (1.6.4-2-notls (i386/linux))
Content-Length: 0

<------------->

You haven’t included the INVITE!

Also, are you making a loop back call using the other account? If so you are confusing the issue, as the From address matches one of your section names, but possibly by accident. Make sure that you call from a mobile phone, or something else completely independent.

Hi David i see my mistake now i think … is this the invite

<— SIP read from UDP:212.11.94.169:5060 —>
INVITE sip:4417811111@x.248.x.84 SIP/2.0
Record-Route: sip:212.11.94.169;lr=on;ftag=8S8P051IJW30000E1D00001u0WM7YOB0VVD79V;did=4ce.12c91571
Via: SIP/2.0/UDP 212.11.94.169;branch=z9hG4bKd28f.e4352233.0
Via: SIP/2.0/UDP 194.145.191.131:5060;branch=z9hG4bK000423E166BE9844231C0A3276CD
From: sip:0776815xxxx@194.145.191.131;tag=8S8P051IJW30000E1D00001u0WM7YOB0VVD79V
To: sip:441789510254@212.11.94.169
Call-ID: bee104006623-509d45b6-238bee99-187d35f8-81e1062@127.0.0.1
CSeq: 16993 INVITE
Contact: sip:194.145.191.131:5060
Allow-Events: refer
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Max-Forwards: 69
Supported: 100rel, timer, replaces
User-Agent: TELES.MGC
Content-Length: 430

v=0
o=- 883973244 0 IN IP4 78.40.243.196
s=session
c=IN IP4 78.40.243.196
t=0 0
m=audio 5940 RTP/AVP 8 0 18 97 2 99 4 80 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 G726-16/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:99 G726-40/8000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=fmtp:4 bitrate=6.3
a=rtpmap:80 G723/8000
a=fmtp:80 bitrate=5.3
a=rtpmap:96 telephone-event/8000
a=sendrecv
<------------->

hope thats right

I don’t think there is anything there that will allow a user match, and as the source IP doesn’t match the official one, I think you either have to do a peer for each possible source address, or allowguest=yes and do some heavy IP address filtering.

As that involves doing things that are considered bad for security, I would suggest waiting to see if anyone else can confirm or deny.

Thats how I have secured our other asterisk boxes but I now have several users with sip phones but there using dynamic Ips

You should be able to configure the phones as registerable (peer with dynamic address) and open up the allows for those peers.

Hi David

i set allowguest=off and add several permit and deny statements but i still receive the
chan_sip.c:22041 handle_request_invite: Sending fake auth rejection for device

can you give me an example of how to configure this ?

cheers

I think you need allowguest=yes, or a better ITSP.

I’ve never had to deal with this situation so I have no examples.