Help with my security - SIP profile

Not open for further replies.


Dec 13, 2017
Guys, I've been hacked, not sure yet how but I was hoping someone with better knowledge can take a look at my SIP profile and let me know if there is anything exposed here. I have several small companies connecting from external and with changing IP's so ACL's won't do..
I set this up with no knowledge or experience, but it's a small enough setup clients wise, 6 tenants on this PBX.
Any advice much appreciated!

accept-blind-authtrue True
accept-blind-regtrue False
aggressive-nat-detectiontrue True
apply-inbound-acldomains True True
apply-register-acldomains False
auth-all-packetsfalse True
auth-calls$${internal_auth_calls True
auto-jitterbuffer-msec60 False
bind-paramstransport=udp False
bitpackingaal2 False
caller-id-typenone False
caller-id-typepid False
caller-id-typerpid True
challenge-realmauto_to True
cid-in-1xxfalse False
contextpublic True
dbnameshare_presence False
debug0 True
delete-subs-on-registerfalse False
dialplanXML True
disable-naptrfalse False
disable-registertrue False
disable-rtp-auto-adjusttrue False
disable-srvfalse False
disable-srv503true False
disable-transcodingtrue False
disable-transfertrue False
dtmf-duration2000 True
dtmf-typerfc2833 True
enable-100reltrue False
enable-3pcctrue False
enable-compact-headerstrue False
enable-timertrue False
extended-info-parsingtrue False
ext-rtp-ip$${external_rtp_ip} True
ext-sip-ip$${external_sip_ip} True
force-register-db-domain$${domain} False
force-register-domain$${domain} False
force-subscription-domain$${domain} False
force-subscription-expires60 False
forward-unsolicited-mwi-notifyfalse True
hold-music$${hold_music} True
inbound-bypass-mediatrue False
inbound-codec-negotiationgenerous True
inbound-codec-prefs$${global_codec_prefs} True
inbound-late-negotiationtrue True
inbound-proxy-mediatrue False
inbound-reg-force-matching-usernametrue True
liberal-dtmftrue True True
log-auth-failurestrue True
manage-presencetrue True
manage-shared-appearancetrue True
manual-redirecttrue False
max-proceeding1000 False
media-optionresume-media-on-hold False
media-optionbypass-media-after-att False
minimum-session-expires120 False
multiple-registrationscontact True
nat-options-pingtrue True
NDLB-allow-bad-iananametrue True
NDLB-broken-auth-hashtrue False
NDLB-force-rportsafe True
NDLB-received-in-nat-reg-contacttrue True
nonce-ttl60 True
odbc-dsn$${dsn} False
outbound-codec-prefs$${global_codec_prefs} True
pass-callee-idfalse False
pass-rfc2833true False
presence-hosts$${domain},$${local_ip False
presence-privacy$${presence_privacy} True
presence-probe-on-registertrue True
presence-proto-lookuptrue False
record-path$${recordings_dir} True
record-template${domain_name}/archive True
registration-thread-frequency30 False
renegotiate-codec-on-holdtrue False
rfc2833-pt101 True
rtcp-audio-interval-msec5000 False
rtcp-video-interval-msec5000 False
rtp-autofix-timingfalse False
rtp-autoflush-during-bridgefalse False
rtp-hold-timeout-sec1800 True
rtp-ip172.16.0.104 True $${local_ip_v4}
rtp-rewrite-timestampstrue False
rtp-timeout-sec600 True
rtp-timer-namesoft True
send-message-query-on-registertrue False
send-presence-on-registertrue False
session-timeout1800 True
shutdown-on-failtrue False
sip-captureno True
sip-ip172.16.0.104 True $${local_ip_v4}
sip-port5080 True $${internal_sip_port}
sip-traceno True
suppress-cngtrue False
timer-T1500 False
timer-T1X6432000 False
timer-T24000 False
timer-T44000 False
tls$${internal_ssl_enable True
tls-bind-paramstransport=tls True
tls-cert-dir$${internal_ssl_dir} True
tls-onlyfalse True
tls-sip-port$${internal_tls_port} True
tls-verify-datetrue True
tls-verify-depth2 True
tls-verify-policyall|subjects_all False
tls-version$${sip_tls_version} True
unregister-on-options-failtrue False
user-agent-stringFreeSWITCH True
vadout False
watchdog-enabledno True
watchdog-event-timeout30000 True
watchdog-step-timeout30000 True
Last edited:

Adrian Fretwell

Well-Known Member
Aug 13, 2017
The first thing I noticed is that $${internal_auth_calls is missing a closing bracket.

There is not much we can tell from a SIP profile alone, for example we don't know the actual value in the $$ variables.

Can you be more specific about what happened? Did they use a password? I assume it was a SIP hack rather than web or ssh.


Dec 13, 2017
Thanks, it actually does include the closing bracket, it's cut it off from view in the columns view, when I click on it it then appears.
I checked as much of the logs as possible the IP displayed as to where the call originated from shows the actual customers IP. Like their handset was hacked with brute force and calls originated from the handset itself...if that's even possible. I had an http port open on their office router for access to the handset, but the handsets password was relatively complex...I've since closed the port and changed the handsets admin password and the extensions...I'm hoping that's how the hack happened but I'm just worried that it's something to do with my sip profile.


Dec 13, 2017
...regarding this statement, "we don't know the actual value in the $$ variables" So should I be not suing the $$variable attribute and rather be setting something exact here?

Adrian Fretwell

Well-Known Member
Aug 13, 2017
No $$ variables are fine. I just meant that I can't tell what they are set to. You probably set some of them in Switch Variables and FreeSWITCH uses defaults for the rest.
I don't think there is a problem with your SIP profile. Someone hacking a customer phone is far more likely. We had that happen a few years ago, there a hacker gained access to a customers LAN. This is one reason why we only provision phones using https, we don't want someone with tcpdump on the LAN reading SIP usernames and passwords.

One more thing to consider. Is there any kind of DISA (Direct Inward System Access)? Some people use this so reps. can dial in on a DDI enter a PIN and then dial out as if they were in the office. It's also worth checking IVRs and Ring groups for any dial through options. For example, some people use a ring group forward or follow me when they go out of the office. If a hacker got access to their web login (if the customer has one), they can easily add a forward to achieve dial through fraud.


New Member
Jul 10, 2018
Was this a Yealink phone?

By default there is a "user" account with password "user". If the phone was open on the Internet via HTTP or HTTPS it could be the case that this was accessed and a high cost fraud destination set as the call forward code. This allows them to make outbound calls by switching on/off call forwarding via that user account. All scripted and configured for maximum impact.

Always restrict the source when opening inbound connections to devices like these. It won't be possible with standard ISP routers in most cases so it is worth investing in a device that does allow more granular configuration options, such as restricting what source is allowed to access the port forward.
Not open for further replies.