I just stood up a new FreePBX instance and there are only 2 extensions connected to it (which are coming from the same legitimate IP) as of this moment but there are numerous entries in the CDRs that look suspicious to me and there are no “real” calls going on. I have attached a screenshot, can anyone provide any input as to what may be going on? A quick Google of ‘hi’or‘x’=‘x’ pops up a bunch of results for a SQL injection. IPTables and Fail2Ban are currently running.
Also I’ve disabled my trunks for the mean time, but these entries still are popping up in my CDR logs it looks like.
Anonymous calls are turned off, so is SIP guests, firewall is on, as well as fail2ban. These are still popping up in my CDRs even with my trunks disabled.
Here’s an excerpt of my log files, some of the things that stuck out at me… I know it’s alot to look at but I’d really appreciate another set of eyes on this to help me figure out what is going on. Thanks Nick
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Registered extension context ‘from-pstn-e164-us’; registrar: pbx_config
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘+1NXXNXXXXXX’ priority 1 (CID match '+1NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘+1NXXNXXXXXX’ priority 2 (CID match ‘NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '+1NXXNXXXXXX’ priority 1 (CID match '+NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘+1NXXNXXXXXX’ priority 2 (CID match ‘011NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '+1NXXNXXXXXX’ priority 1 to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 1 (CID match ‘+1NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 1 (CID match ‘1NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 2 (CID match ‘NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 1 (CID match ‘+NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 2 (CID match ‘011NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '[0-9+].’ priority 1 to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘s’ priority 1 (CID match ‘_+1NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘s’ priority 2 (CID match ‘NXXNXXXXXX’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘s’ priority 1 (CID match '+NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘s’ priority 2 (CID match ‘011NX.’) to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension ‘s’ priority 1 to from-pstn-e164-us
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Registered extension context ‘from-pstn-toheader’; registrar: pbx_config
[2017-02-25 17:08:06] WARNING[20863] pbx_config.c: The use of '.’ for an extension is strongly discouraged and can have unexpected behavior. Please use ‘X.’ instead at line 127 of extensions.conf
[2017-02-25 17:08:06] VERBOSE[20863] pbx.c: – Added extension '.’ priority 1 to from-pstn-toheader
[2017-02-25 17:08:06] WARNING[20863] pbx.c: Unable to register extension ‘s’ priority 1 in ‘macro-outisbusy’, already in use
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [+865580048555550192@from-sip-external:1] NoOp(“SIP/107.155.85.53-00000005”, “Received incoming SIP connection from unknown peer to +865580048555550192”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [+865580048555550192@from-sip-external:2] Set(“SIP/107.155.85.53-00000005”, “DID=+865580048555550192”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [+865580048555550192@from-sip-external:3] Goto(“SIP/107.155.85.53-00000005”, “s,1”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Goto (from-sip-external,s,1)
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:1] GotoIf(“SIP/107.155.85.53-00000005”, “0?checklang:noanonymous”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Goto (from-sip-external,s,5)
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:5] Set(“SIP/107.155.85.53-00000005”, “TIMEOUT(absolute)=15”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] func_timeout.c: – Channel will hangup at 2017-02-25 17:09:25.392 CST.
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:6] Log(“SIP/107.155.85.53-00000005”, "WARNING,“Rejecting unknown SIP connection from 62.210.244.196"”) in new stack
[2017-02-25 17:09:10] WARNING[21142][C-00000005] Ext. s: “Rejecting unknown SIP connection from 62.210.244.196”
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:7] Answer(“SIP/107.155.85.53-00000005”, “”) in new stack
[2017-02-25 17:09:10] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:8] Wait(“SIP/107.155.85.53-00000005”, “2”) in new stack
[2017-02-25 17:09:12] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:9] Playback(“SIP/107.155.85.53-00000005”, “ss-noservice”) in new stack
[2017-02-25 17:09:12] VERBOSE[21142][C-00000005] file.c: – <SIP/107.155.85.53-00000005> Playing ‘ss-noservice.ulaw’ (language ‘en’)
[2017-02-25 17:09:18] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:10] PlayTones(“SIP/107.155.85.53-00000005”, “congestion”) in new stack
[2017-02-25 17:09:18] VERBOSE[21142][C-00000005] pbx.c: – Executing [s@from-sip-external:11] Congestion(“SIP/107.155.85.53-00000005”, “5”) in new stack
[2017-02-25 17:09:23] VERBOSE[21142][C-00000005] pbx.c: == Spawn extension (from-sip-external, s, 11) exited non-zero on ‘SIP/107.155.85.53-00000005’
[2017-02-25 17:09:23] VERBOSE[21142][C-00000005] pbx.c: – Executing [h@from-sip-external:1] Hangup(“SIP/107.155.85.53-00000005”, “”) in new stack
[2017-02-25 17:09:23] VERBOSE[21142][C-00000005] pbx.c: == Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/107.155.85.53-00000005’
[2017-02-25 17:09:42] WARNING[19819] chan_sip.c: Retransmission timeout reached on transmission LCLIJNCVYJOWVEAFQURJSTRZ for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Is there a way to manually ban an IP? I see some weird activity coming from a certain IP that isn’t registered to any extension on my system and I’d like to ban if if possible?
Under SIP Channels, I see this.
62.210.245.31 â��hi’orâ��xâ�� SZBMHWVZDYQYZDK (ulaw) No Rx: INVITE
But that IP isn’t registered to anything and I have SIP Guests turned off… Any ideas?
I think it is resolved, I could have sworn I had SIP guests turned off but it was ticked on… turned it off and nothing suspicious since then… I’ll post back in 10 or 15 to confirm it is resolved. Thanks for the help thus far.
Yes, that machine is in a well known “bad-guy” cloud service (Iliad)
iptables -A INPUT -s 62.210.0.0/16 -j DROP
will fix many of these knuckle-draggers but make sure you have anonymous and guest SIP peers denied and that your Firewall/IDS systems are working properly. Do similar if you see more attacks, they will invariably come . . .
I wonder if this will work though if you are running the FreePBX firewall, these might very well get overwritten…
I assume this is a VPS or something similar?
How many IPs need to access the PBX?
Are these static IPs?
You could allow traffic only from those IPs (and your providers) and there would be no chance of someone trying to abuse your system like this…
Even if they are not static IPs you could run a software that dynamically updates a DNS entry with their current IP and uses those hostnames in your firewall rules. The firewalls which allow this reevaluate those hostnames from time to time and I do believe the FreePBX one does…
Firewall rules ARE your firewall., if you have another one on your border, that is commendable.
I suggested apart from the common fixs about allowing sip access, to ensure " . . .that your Firewall/IDS systems are working properly . . ." if they aren’t then they need fixing prior to rebooting and also after rebooting., personally I use fail2ban,csf and ipsets from many publicly available blacklists , and only have very rare problems , new shit will always show up perhaps this portends the latest one
p.s. (I am still perplexed why anybody s using 5000-5900 for any SIP connections, it is totally unnecessary and totally attracts flies like honey)
p.p.s ( want to be more global at blocking?, look at
http://pwhois.org/lf
You can easily ban whole networks with little effort pre-emptively using ipsets )
I got hit with the same thing last night… Blocked entire continents via my firewall, so problem stopped at my main firewall. haven’t seen anything since then.
. . .