Like most people with an exposed-to-the-Internet PBX, hack attempts are too numerous to count. My fail2ban script does a good job of killing them quickly.
I am running asterisk 13.21-cert3 (latest) on an up-to-date CentOS7 server. Something just happened that sort of freaked me out. I have a few static SIP peers (for internal asterisk-to-asterisk communications). For example, on the relevant PBX I have a SIP friend calls PBX7, with ip 192.168.1.7 .
Suddently, while debugging something else I started seeing a lot of failed INVITES - messages I am not used to seeing. After a quick investigation, I realized by typing the command “sip show peer pbx7” that the address of this friend (host=192.168.1.7, so static) had now become 188.161.194 (quick search shows that it came from the Palestinian territory). I quickly reloaded sip with “sip reload” (and blocked the relevant Palestinian IPs).
That being said, how can a SIP friend/user/whatever that is set to be configured statically change IP suddently? I don’t even know where to start looking.
I looked at all the usual suspects here:
- There was no console login (root or otherwise) besides my own
- The SIP settings for PBX7 in the sip.conf file had not changed (still 192.168.1.7)
- All services are firewalled to the world except for VoIP related (SIP and RTP)
Here is my sip show peer for this PBX7 peer (after the SIP reload, I didnt think of running this while the “hack” was going on.
- Name : pbx7
Realtime peer: No
Context : some_context
Record On feature : automon
Record Off feature : automon
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Named Callgr :
MOH Suggest :
VM Extension : asterisk
LastMsgsSent : 0/0
Call limit : 0
Max forwards : 0
Dynamic : No
Callerid : “” <>
MaxCallBR : 384 kbps
Expire : -1
Insecure : no
Force rport : Auto (No)
Symmetric RTP: No
ACL : No
DirectMedACL : No
T.38 support : No
T.38 EC mode : Unknown
T.38 MaxDtgrm: 4294967295
DirectMedia : No
PromiscRedir : No
User=Phone : No
Video Support: No
Text Support : No
Ign SDP ver : No
Trust RPID : Yes
Send RPID : Yes
Path support : No
Path : N/A
Overlap dial : Yes
DTMFmode : rfc2833
Timer T1 : 500
Timer B : 32000
ToHost : 192.168.1.7
Addr->IP : 192.168.1.7:5060
Defaddr->IP : (null)
Prim.Transp. : UDP
Allowed.Trsp : UDP
SIP Options : replaces replace timer
Codecs : (ulaw)
Auto-Framing : No
Status : OK (1 ms)
Reg. Contact :
Qualify Freq : 60000 ms
Keepalive : 0 ms
Sess-Timers : Accept
Sess-Refresh : uas
Sess-Expires : 1800 secs
Min-Sess : 90 secs
RTP Engine : asterisk
Use Reason : No
Encryption : No
RTCP Mux : No
So, the real/underlying question here is: how can a host=192.168.1.7 suddently become to “host=188.161.194” without human intervention?
I’d undertstand if it was a host=dynamic type of thing, but it wasn’t
You can protect your SIP peer using acl.conf or using sip option deny/permit
Not sure how this is relevant for a SIP that has a static IP defined. Doesn’t this imply a “permit” only for that IP?
(really asking for my comprehension - I may be misunderstanding something)
You didn’t provide the actual configuration, but this is one of the reasons why the standard cookbook approach of using type=friend is wrong.
type=friend will accept a call if either the user part of the From header matches the section name, or the host IP address matches, and will prefer a user part match.
This was indeed my config before I changed it an hour ago to type=peer:
So you’re saying that this might have been the hole in which somebody succeeded in inserting their IP address?
I did finally get a shot of the config after the hack, the sip show peer command showed this:
ToHost : 192.168.1.7
Addr->IP : 188.161.194:8886
It is a hole through which they could masquerade as pbx7. It wouldn’t allow them to change the configuration
Type=friend on local devices can also be attacked, although they normally have passwords.
I’m sharing an useful information that help you to understand this better.
This is always a confusing part of the chan_sip SIP channel driver.
Rather than try to dig into any history, here is the current documentation (from sip.conf.sample in the Asterisk source of
1.8,11,12) that you should base your decision to use a particular
“; SIP entities have a ‘type’ which determines their roles within Asterisk.
; * For entities with ‘type=peer’:
; Peers handle both inbound and outbound calls and are matched by ip/port, so for
; The case of incoming calls from the peer, the IP address must match in order for
; The invitation to work. This means calls made from either direction won’t work if
; The peer is unregistered while host=dynamic or if the host is otherise not set to
; the correct IP of the sender.
; * For entities with ‘type=user’:
; Asterisk users handle inbound calls only (meaning they call Asterisk, Asterisk can’t
; call them) and are matched by their authorization information
(authname and secret).
; Asterisk doesn’t rely on their IP and will accept calls regardless of the host setting
; as long as the incoming SIP invite authorizes successfully.
; * For entities with ‘type=friend’:
; Asterisk will create the entity as both a friend and a peer. Asterisk will accept
; calls from friends like it would for users, requiring only that the authorization
; matches rather than the IP address. Since it is also a peer, a friend entity can
; be called as long as its IP is known to Asterisk. In the case of host=dynamic,
; this means it is necessary for the entity to register before Asterisk can call it.”
Most new work for SIP support in Asterisk is happening around res_pjsip. I don’t know that there is any plans to deprecate type=user going forward in chan_sip.
New installs of older Asterisk versions? That doesn’t sound wise, seeing as the 1.6 branch doesn’t have any support, even for security issues… A new install of Asterisk should be on a version of Asterisk supported by the developers. Right now, that would be the latest of the 1.8,11, or 12 branches. That being said, 12 is rather new and has many significant changes that should be considered.
Thanks for the info @david551 and @ambiorixg12 - I guess I should have known that, I simply assumed host=static_ip was sufficient to completely restrict the SIP user to that static IP. I changed all my none-passworded SIP friends to peers, hoping this fixes it once and for all.