Hacking attempts?

Hi all,

We’ve noticed something strange on our PBX recently, please see log below.
Unfortunately setting Allow SIP guests to No is not an option as the calls will fail as it’s required by our SIP provider to be on.

[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:1] NoOp(“SIP/MYIP-000211ce", “Received incoming SIP connection from unknown peer to 000972592115219”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:2] Set("SIP/ MY
IP -000211ce”, “DID=000972592115219”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:3] Goto(“SIP/ MYIP -000211ce", “s,1”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Goto (from-sip-external,s,1)
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:1] GotoIf("SIP/ MY
IP -000211ce”, “1?checklang:noanonymous”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Goto (from-sip-external,s,2)
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:2] GotoIf(“SIP/ MYIP -000211ce", “0?setlanguage:from-trunk,000972592115219,1”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Goto (from-trunk,000972592115219,1)
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:1] Set("SIP/ MY
IP -000211ce”, “__FROM_DID=000972592115219”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:2] NoOp(“SIP/ MYIP -000211ce", “Received an unknown call with DID set to 000972592115219”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:3] Goto("SIP/ MY
IP -000211ce”, “s,a2”) in new stack
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Goto (from-trunk,s,2)
[2015-10-28 10:54:09] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:2] Answer(“SIP/ MYIP -000211ce", “”) in new stack
[2015-10-28 10:54:10] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:3] Log("SIP/MY
IP-000211ce”, “WARNING,Friendly Scanner from 67.227.191.133”) in new stack
[2015-10-28 10:54:10] WARNING[15220][C-000210cf] Ext. s: Friendly Scanner from 67.227.191.133
[2015-10-28 10:54:10] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:4] Wait(“SIP/ MYIP -000211ce", “2”) in new stack
[2015-10-28 10:54:12] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:5] Playback("SIP/ MY
IP -000211ce”, “ss-noservice”) in new stack
[2015-10-28 10:54:12] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘ss-noservice.alaw’ (language ‘en’)
[2015-10-28 10:54:17] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:6] SayAlpha("SIP/MY
IP-000211ce", “000972592115219”) in new stack
[2015-10-28 10:54:17] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/0.alaw’ (language ‘en’)
[2015-10-28 10:54:18] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/0.alaw’ (language ‘en’)
[2015-10-28 10:54:18] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/0.alaw’ (language ‘en’)
[2015-10-28 10:54:19] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/9.alaw’ (language ‘en’)
[2015-10-28 10:54:20] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/7.alaw’ (language ‘en’)
[2015-10-28 10:54:21] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/2.alaw’ (language ‘en’)
[2015-10-28 10:54:21] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/5.alaw’ (language ‘en’)
[2015-10-28 10:54:22] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/9.alaw’ (language ‘en’)
[2015-10-28 10:54:23] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/2.alaw’ (language ‘en’)
[2015-10-28 10:54:23] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/1.alaw’ (language ‘en’)
[2015-10-28 10:54:24] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/1.alaw’ (language ‘en’)
[2015-10-28 10:54:25] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/5.alaw’ (language ‘en’)
[2015-10-28 10:54:25] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/2.alaw’ (language ‘en’)
[2015-10-28 10:54:26] VERBOSE[15220][C-000210cf] file.c: – <SIP/MY
IP-000211ce> Playing ‘digits/1.alaw’ (language ‘en’)
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] file.c: – <SIP/MYIP-000211ce> Playing ‘digits/9.alaw’ (language ‘en’)
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:7] Hangup("SIP/MY
IP-000211ce", “”) in new stack
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: == Spawn extension (from-trunk, s, 7) exited non-zero on ‘SIP/MYIP-000211ce’
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:1] Macro("SIP/MY
IP-000211ce", “hangupcall,”) in new stack
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:1] ExecIf(“SIP/MYIP-000211ce", “0?Set(CDR(recordingfile)=.)”) in new stack
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211ce”, “1?theend”) in new stack
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Goto (macro-hangupcall,s,4)
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: – Executing [[email protected]:4] Hangup("SIP/MYIP-000211ce", “”) in new stack
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/MY
IP-000211ce’ in macro ‘hangupcall’
[2015-10-28 10:54:27] VERBOSE[15220][C-000210cf] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/MYIP-000211ce’
[2015-10-28 10:54:41] WARNING[9546] chan_sip.c: Retransmission timeout reached on transmission 9dfb5891f9008d0e7a99b97abdea31d2 for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 31999ms with no response
[2015-10-28 10:56:48] VERBOSE[9546][C-000210d0] netsock2.c: == Using SIP RTP TOS bits 184
[2015-10-28 10:56:48] VERBOSE[9546][C-000210d0] netsock2.c: == Using SIP RTP CoS mark 5
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:1] NoOp("SIP/MY
IP-000211cf", “Received incoming SIP connection from unknown peer to 9007970598371060”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:2] Set(“SIP/MYIP-000211cf", “DID=9007970598371060”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:3] Goto("SIP/MY
IP-000211cf”, “s,1”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Goto (from-sip-external,s,1)
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:1] GotoIf(“SIP/MYIP-000211cf", “1?checklang:noanonymous”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Goto (from-sip-external,s,2)
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211cf”, “0?setlanguage:from-trunk,9007970598371060,1”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Goto (from-trunk,9007970598371060,1)
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:1] Set(“SIP/MYIP-000211cf", “__FROM_DID=9007970598371060”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:2] NoOp("SIP/MY
IP-000211cf”, “Received an unknown call with DID set to 9007970598371060”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:3] Goto(“SIP/MYIP-000211cf", “s,a2”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Goto (from-trunk,s,2)
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:2] Answer("SIP/MY
IP-000211cf”, “”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: == Spawn extension (from-trunk, s, 2) exited non-zero on ‘SIP/MYIP-000211cf’
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:1] Macro("SIP/MY
IP-000211cf", “hangupcall,”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:1] ExecIf(“SIP/MYIP-000211cf", “0?Set(CDR(recordingfile)=.)”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211cf”, “1?theend”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Goto (macro-hangupcall,s,4)
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: – Executing [[email protected]:4] Hangup("SIP/MYIP-000211cf", “”) in new stack
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/MY
IP-000211cf’ in macro ‘hangupcall’
[2015-10-28 10:56:48] VERBOSE[15304][C-000210d0] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/MYIP-000211cf’
[2015-10-28 10:58:18] VERBOSE[9546][C-000210d1] netsock2.c: == Using SIP RTP TOS bits 184
[2015-10-28 10:58:18] VERBOSE[9546][C-000210d1] netsock2.c: == Using SIP RTP CoS mark 5
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:1] NoOp("SIP/MY
IP-000211d0", “Received incoming SIP connection from unknown peer to 60061261760726”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:2] Set(“SIP/MYIP-000211d0", “DID=60061261760726”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:3] Goto("SIP/MY
IP-000211d0”, “s,1”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Goto (from-sip-external,s,1)
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:1] GotoIf(“SIP/MYIP-000211d0", “1?checklang:noanonymous”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Goto (from-sip-external,s,2)
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211d0”, “0?setlanguage:from-trunk,60061261760726,1”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Goto (from-trunk,60061261760726,1)
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:1] Set(“SIP/MYIP-000211d0", “__FROM_DID=60061261760726”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:2] NoOp("SIP/MY
IP-000211d0”, “Received an unknown call with DID set to 60061261760726”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:3] Goto(“SIP/MYIP-000211d0", “s,a2”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Goto (from-trunk,s,2)
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:2] Answer("SIP/MY
IP-000211d0”, “”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: == Spawn extension (from-trunk, s, 2) exited non-zero on ‘SIP/MYIP-000211d0’
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:1] Macro("SIP/MY
IP-000211d0", “hangupcall,”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:1] ExecIf(“SIP/MYIP-000211d0", “0?Set(CDR(recordingfile)=.)”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211d0”, “1?theend”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Goto (macro-hangupcall,s,4)
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: – Executing [[email protected]:4] Hangup("SIP/MYIP-000211d0", “”) in new stack
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/MY
IP-000211d0’ in macro ‘hangupcall’
[2015-10-28 10:58:18] VERBOSE[15338][C-000210d1] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on 'SIP/MYIP-000211d0’
[2015-10-28 10:59:04] VERBOSE[9546][C-000210d2] netsock2.c: == Using SIP RTP TOS bits 184
[2015-10-28 10:59:04] VERBOSE[9546][C-000210d2] netsock2.c: == Using SIP RTP CoS mark 5
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:1] NoOp("SIP/MY
IP-000211d1", “Received incoming SIP connection from unknown peer to 00972592634285”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:2] Set(“SIP/MYIP-000211d1", “DID=00972592634285”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:3] Goto("SIP/MY
IP-000211d1”, “s,1”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Goto (from-sip-external,s,1)
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:1] GotoIf(“SIP/MYIP-000211d1", “1?checklang:noanonymous”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Goto (from-sip-external,s,2)
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211d1”, “0?setlanguage:from-trunk,00972592634285,1”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Goto (from-trunk,00972592634285,1)
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:1] Set(“SIP/MYIP-000211d1", “__FROM_DID=00972592634285”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:2] NoOp("SIP/MY
IP-000211d1”, “Received an unknown call with DID set to 00972592634285”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:3] Goto(“SIP/MYIP-000211d1", “s,a2”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Goto (from-trunk,s,2)
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:2] Answer("SIP/MY
IP-000211d1”, “”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: == Spawn extension (from-trunk, s, 2) exited non-zero on ‘SIP/MYIP-000211d1’
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:1] Macro("SIP/MY
IP-000211d1", “hangupcall,”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:1] ExecIf(“SIP/MYIP-000211d1", “0?Set(CDR(recordingfile)=.)”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:2] GotoIf("SIP/MY
IP-000211d1”, “1?theend”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Goto (macro-hangupcall,s,4)
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: – Executing [[email protected]:4] Hangup("SIP/MYIP-000211d1", “”) in new stack
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] app_macro.c: == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/MY
IP-000211d1’ in macro ‘hangupcall’
[2015-10-28 10:59:04] VERBOSE[15369][C-000210d2] pbx.c: == Spawn extension (from-trunk, h, 1) exited non-zero on ‘SIP/MY*****IP-000211d1’
[2015-10-28 11:01:59] VERBOSE[9546][C-000210d3] netsock2.c: == Using SIP RTP TOS bits 184
[2015-10-28 11:01:59] VERBOSE[9546][C-000210d3] netsock2.c: == Using SIP RTP CoS mark 5

Any ideas on how to stop this?? it happens every 2-3 minutes flooding our PBX.
The PBX is sat behind the firewall and even though I have acl set to stop the traffic from specific IP’s it still comes up on PBX for some reason.
FreePBX 12.0.76.2
PBX Firmware: 6.12.65-26

Also we have problem with below:

[2015-10-28 09:52:53] NOTICE[9546] chan_sip.c: Registration from ‘“100200” sip:[email protected]:5060***IP’ failed for ‘212.83.148.18:5067’ - Wrong password
[2015-10-28 09:57:06] NOTICE[9546] chan_sip.c: Registration from ‘“ranjan” sip:[email protected]:5060***IP’ failed for ‘212.83.148.18:5069’ - Wrong password
[2015-10-28 10:01:11] NOTICE[13184] manager.c: 84.244.139.25 tried to authenticate with nonexistent user ‘user’
[2015-10-28 10:01:11] NOTICE[13184] manager.c: 84.244.139.25 failed to authenticate as ‘user’
[2015-10-28 10:06:00] NOTICE[9546] chan_sip.c: Registration from ‘“sanjay” sip:[email protected]:5060***IP’ failed for ‘212.83.148.18:5081’ - Wrong password
[2015-10-28 10:23:38] NOTICE[9546] chan_sip.c: Registration from ‘“19791” sip:[email protected]:5060***IP’ failed for ‘212.83.148.18:5065’ - Wrong password
[2015-10-28 10:34:37] NOTICE[14236] manager.c: 84.244.139.25 tried to authenticate with nonexistent user ‘mark’
[2015-10-28 10:34:37] NOTICE[14236] manager.c: 84.244.139.25 failed to authenticate as ‘mark’
[2015-10-28 10:53:31] NOTICE[9546][C-000210ca] chan_sip.c: Failed to authenticate device 1111sip:[email protected]***IP;tag=ac4d6f93
[2015-10-28 11:09:33] WARNING[15706][C-000210d8] Ext. s: Friendly Scanner from 5.189.190.120
[2015-10-28 11:09:39] WARNING[15713][C-000210d9] Ext. s: Friendly Scanner from 23.239.66.51

What worries me here is that one of the extensions actually exists on our system

Thanks for help in advance.

Try upgrading to 13 and installing and configuring the Firewall module, see recent blogs for more information. Note, this does not have to replace your existing firewall if you have one, it can simply supplement it.

Hi,

I would not suggest to upgrade to Freepbx 13 on the existing server. It is better to secure the server locally. All you need to do is tighten your iptables with fail2ban and dynamic scripts to add the blocking ip’s permanently to the iptables firewall.

I can help you if you want.

Thank you,

Daniel Friedman
Trixton LTD.

Mobile: +41.79.868.7050
Email: [email protected]

Daniel,

can you explain on what authority you would recommend not upgrading to 13 and not using the new firewall?

Version 13 is overall more secure then previous versions. Furthermore, the new firewall provides very intuitive capabilities to control iptables, works in conjunction with fail2ban (not instead), and there are ‘dynamic’ capabilities within it that can be enabled depending on what types of outside access are requried by eyeballpaul’s system.

To make such a blanket statement, and then turns around and says “secure the system locally with iptables” which is exaclty what the Firewall module does, plus a lot more, seems quite confusing to someone seeking help here?

If there are specific issues that you feel are of concern, how about you lay them out?

Thanks for the answers.

I would try both solutions if this is possible.

Daniel can you please post the scripts you are talking about?

Also the swap between versions seems easy but will it keep all my configuration intact?
We’ve experienced quite a lot of issues when we’ve changed the firewalls recently, and I can’t afford the phone outage again.

upgrading versions definitely keeps your configuration intact. Still always a good idea to do a backup prior to any upgrade, but you should be ok. There are thousdands of systems alread on 13.

I would caution you on running any outside scripts unless you fully understand what they do. One of many motivating factors of the introdcution of the firewall module was because of the vast amount of carnage we’ve seen from people running outside scritps that they don’t understand. More often then not, you find most of such scripts are not aware of what FreePBX or other aspects of the system is doing and they are usually much more likely to create problems.

Again, if you fully understnad them, and are quite versed in FreePBX and internals, you may be ok but given your questions, I’m guessing that may not be quite your comfort zone?

Hi Philippe,

Did you ever considered that he has a running system???
An upgrade to the Freepbx 13 would be devastating and can ruin his PBX. Furthermore, the new 13 version is unstable yet, and I am gentle with you.

can you explain on what authority you would recommend not upgrading to 13 and not using the new firewall?

You must be joking and I would not respect that in a decent answer.

And let me finish with a personal attitude:

The new firewall module of Rob is a blessed thing, and I even shared with him my scripts for protecting the Asterisk and Linux environment. But never the less it will take a long time to test and evaluate the new behavior of the firewall module.

Thank you,

Daniel Friedman
Trixton LTD.

Daniel,

You are making some pretty blanket and harsh statements. Version 13 is actually quite stable, the ‘beta’ marking on it is really just a formality as we were going to release it a few weeks before Astricon and then decided to coniniced with Astricon. In the typical form of feature creep we decided to add some navigation aids to it which is going on right now. With all that said, none of that has anything to do with the dialplan and operational aspects of the PBX which go through a more rigourous level of stability evaluation.

There are several thousand systems running 13, and we make our asseesments based on data, not unsubstantiated comments or one off situations. We look at bug rates, the types of bugs coming in, etc. As is normally the case with new releases, there are often more bugs reported that have been bugs for a long time and on earlier releases because of the wave of evaluation that happens on a new release. We often make the judgement call to fix many of these bugs only on the newest release for various reasons. As such, there is often more stability, expecially at the PBX core / dialplan level, on existing functionality.

You state words like upgrading to 13 would be a disaster? So there are thousdands of users out there in a disatorous state? I have a fundamtal issue with such statements without knowing any details of this user’s system, what he uses, the environment, etc. It’s a very irresponsible statement to make and it comes with no data.

You say I must be joking? So why it is that you “aren’t joking” when suggesting someone take a ‘blind’ set of scripts and firewall rules and plop them on a system?

Thus … all of this my reason why I ask what ‘authority’ you have in making such bold statements. I am not making any statements as to what level of knowledge or experience you have, but I am taking exception to your blanket and bold statements that come with no data or no reasoning and are presented in what might come across as pretty ‘arrogant’ statements. Such suggestions don’t provide a lot of value.

As far as your comments on the Firewall, I’m sure Rob was appreciative of anything you shared and looked at it closelfy to take any useful suggestions or comments. It’s open source, it can be evlauated very closely by anyone who wants to. And the dynamic elements of it can be easily turned off if one simply wants to take advantage of the ability to add static IP table rules. It will definitely evolve to something even better than it is today, but in the end it is transparent and well documented. It also had the benefit of a development team that is extremely responsive to issues that come up, which is one big advantage over various one off scripts that are out there.

As mentioned, I don’t know anything about your specific work, what I do know is how many issues and how much carnage that is regularly cleaned up form random scripts and other things being tossed on systems that people don’t understand and very often the original developers didn’t really understand. I have not seen any of your direct work (to my knowledge) so in your case, I have not opinion or judgement. I do, as already mentioned, to have concerns about the blanket statements that I mentioned above.

Try this:
http://wiki.freepbx.org/pages/viewpage.action?pageId=33882179
This beats the new firewall module hands down.

The firewall module does everything in that wiki article you wrote… and much more.

Unfortunately it does not - or did not a few weeks ago.
The Voip blacklisting stopped 99.99% + attempts at hacking a test system I trialled.
Does the firewall support the Voip Blacklist yet?

Graham,

I don’t understand why you feel the need to make such ‘bold’ statements especially within a space that is so unclear. There are solutions that beat the firewall module ‘hands down’ and beat your proposed solution ‘hands down’. Unplug the internet, there you go.

Blacklists can clearly be a positive component of a permiter defense. The downside of blacklists is that they only block against what is ‘known’ and not what is emerging. In additon the attack modes and sophistication is ever evolving.

You will also find that the attack sources vary somewhat based on the geographic location of the PBX. The initial goal of the firewall, in addition to ‘standard’ firewall abilities like blocking everything that we know we don’t want on the system, was to address some of these areas. This is accomplished by adding some local ‘static’ and local ‘dynamic’ intelligence. The static part is to use the FreePBX configuration itself to determine what needs to be whitelisted such as the IP address of configured SIP providers. If none configured, none are whitelisted. If their address changes, the firewall changes, …

The dynamic approach is to provide a permiter defense that will SIGNIFICNALY reduce the chance of a brute force attack in such a way as to block its ability to successfully attack you outside of the off chance that it hits a bullseye on your system on the first few tries. High quality passwords are always recommended, but if you use almost any password that isn’t the extension number, it’s almost certain that a brute force attack won’t be successful before it is locked out by both the firewall rules, as well as the fail2ban which is available as a second permiter of defense.

That doesn’t mean that your proposed blacklist is wrong, and you should be able to use your blacklist in conjucntion with the firewall if it’s using its own chains (I haven’t looked, so I can’t confirm, but conceptually it shouldn’t be a problem). And more defenses willl usually add more security unless they happen to do something that undermines other solutions (like short circuit the security abilities of another system).

But the crux of all of this, and why I continue to take exception to statements such as ‘beats the new firewall hands down’ is that the space is evolvling and solutions need to evlove with the threats that are occuring. Blacklists are one component (and not something we’ve discounted at all). Most importantly, and one of the reasons we put out the firewall, is provide a solution that is easy to use, intuitive so customers use it and don’t turn it off because of probelms they’re having and an inability to understand what they implemented, and most importnaly that will evolve along with updates that can be automatically installed on a users system through the mechanisms that are keeping the rest of their systems up to date.

1 Like

I can only talk about what I saw in testing with a real test system open to the internet.

I tested a dynamic firewall that would spot any issues and block them using fail2ban etc (as documented in the wiki page)
It spotted intrusions and dynamically blocked them

Did this work? Only partly
Why?
What appeared to be happening from a log analysis was that the sites would nibble away at their testing. I would see a block of ips that would attack in concert and appeared to be working co-operatively.
Every time I restarted, they would get a little further in their testing as my dynamic intrusion would reset.

The lesson I learnt from real world testing … dynamic intrusion prevention is vital, but can only be part of the larger picture.

You MUST persist your blacklists.

If all sites perform dynamic testing and dynamic blocking blacklisting performs a critical role in that the framework automatically feeds the list of ips that are performing scanning into a central list. When several sites report it, that ip gets blacklisted.

This means that when you restart your firewall (or the fail2ban expires) … you are not vulnerable to that block of ips working together to get into your system because the blacklist protects you. If you rely purely on dynamic blocking, then ultimately how long it takes them to get in becomes a function of how locked down your system is DIVIDED BY how often you restart your system (or the fail2ban expires) and again DIVIDED BY the size of the ip pool they are using in a coordinated breach attempt.

I have clear evidence from real world testing to back this statement up, and would refer you to email spam testing and blacklisting where similar problems have been examined.

I would be interested in your comparison of real world test system breach times based on pure dynamic vs dynamic backed with blacklisted systems.

My testing, as I mentioned, shows that a combination of both backlisting and dynamic blocking wins hands down.
I state this empirically.

1 Like

I would concur, dynamically adding vectors as they come up is one thing, using a cloud sourced blacklist will leverage above and beyond that pedentry, so any large set from a blacklist will benefit by the use of ipset, the voipbl could benefit by using hash:net and looking it up first, a full 45% of that list are from PS (palestine)

5.11.40.0/22       # RIPE    PS PS-ORANGE-PALESTINE                      Orange Palestine Group Co. for Technological Investment Joint Stock Private Company
5.133.24.0/22      # RIPE    PS PS-ULTRANET-20120704                     Ultranet for Communication and Information Technology Ltd
31.186.176.0/22    # RIPE    PS NETWORK2                                 SuperLink ADSL Service 2
31.223.176.0/21    # RIPE    PS CITYNET                                  citynet internet provider
37.75.208.0/22     # RIPE    PS PS-ORANGE-PALESTINE                      Orange Palestine Group Co. for Technological Investment Joint Stock Private Company
37.8.0.0/18        # RIPE    PS HBSAGAZA                                 Hadara Gaza BSA
46.32.208.0/21     # RIPE    PS CallU_ADSL                               Call U Communications Ltd
64.182.127.160/29  # ARIN    PS ASR-IT-REASSIGN-10                       ASR-IT.COM For Web Services
82.102.216.0/21    # RIPE    PS Hadara_BSA_02                            BSA network expansion
82.205.0.0/22      # RIPE    PS GZ-BSA-01                                Hadara BSA 2013 3/4
83.244.0.0/20      # RIPE    PS PALTEL-SFI                               Palestine Telecommunications Company (PALTEL)httpSubscription Free Internet Program "SFI"
85.113.96.0/20     # RIPE    PS HADARA                                   Hadara-RH3
85.114.96.0/21     # RIPE    PS FUSION-SERVICES                          fusion company IP's
104.243.47.8/29    # ARIN    PS NET-104-243-47-8-29                      naeem syam
176.106.40.0/21    # RIPE    PS SPEED-CLICK-LTD                          SpeedClick for Information Technology and Communication Ltd
176.58.64.0/22     # RIPE    PS netstream                                first_assignment
176.67.98.0/23     # RIPE    PS PS-MADA-ALARAB-20110610                  Gaza-Network
185.12.184.0/23    # RIPE    PS CITYNET                                  citynet internet provider
185.19.220.0/23    # RIPE    PS PS-ORANGE-PALESTINE                      Orange Palestine Group Co. for Technological Investment Joint Stock Private Company
185.33.168.0/24    # RIPE    PS PS-DCC-MNT                               DCC-Infrastructure
185.40.194.0/24    # RIPE    PS HBSAexp03                                Hadara BSA 2013 expansion 3/4
185.5.220.0/22     # RIPE    PS PS-SPEEDCLICK-20121005                   SpeedClick for Information Technology and Communication Ltd
185.6.16.0/22      # RIPE    PS PS-NETSTREAM-20121008                    Netstream Technology Joint-Stock Private Ltd.
188.161.0.0/19     # RIPE    PS PALTEL-DSL                               Palestine Telecommunications Company (PALTEL)
212.106.76.192/27  # RIPE    PS RJ-NET                                   Royal Jordanian
213.244.66.0/24    # RIPE    PS PALTEL-GAZA-POP                          Palestine Telecommunications Company (PALTEL)Gaza IP POPGaza, Palestine
217.66.234.0/23    # RIPE    PS FIXED_IP_GAZA                            Fixed IPs for GAZA BSA
217.78.56.0/21     # RIPE    PS INTERPAL-ADSL-POOL                       INTERPAL-ADSL-POOL

the second worst offender is the US but be careful there if you are from the US as you will get all the ATT’s/Apple/verizon/comcast nets that you need to process by a “secondary inspection”

But SERIOUSLY, consider only answering to SIP on a port other than 5000-5099, it’s a no brainer that will reduce the driveby’s by 99.99%. To compute a reasonable port to use

echo $(($RANDOM + 20001 ))

To say your technique beats the firewall module hands down because it’s only missing voip blacklisting is a very big statement. I hope you’ll agree with me that it’s good In other area and perhaps next time you won’t make such broad statements but will explain your answer in full like you did after Philippe asked you for the betterment of the community. Remember that someone spent time on that module the same as you spent time on your wiki article. Would you like it if we just said general statements like that about your work. Thank you for your consideration.

I think it’s pretty obvious that the words “hands down” are either hyperbole, or opinion, or both. There’s no reason to get upset about someone using them.

IMHO, nothing beats unplugging the internet. As a close second, keep your system safely behind a NAT firewall, and don’t open any ports except those directly related to outbound traffic.

All Valid points.

So in order of preference:

  1. Don’t open a public SIP port to the internet
  2. If you need Voip on the move, prefer using a VPN so you are not exposing a public Voip port
  3. If you have to open a port, open a non standard SIP port
  4. Get really paranoid - add good logging, call reporting, a good password policy, and the firewall (as discussed separately in detail)

For everybody - option 4 comes with risk and should be avoided where possible as you are opening yourself to being hacked. A firewall is only part of what you need (imagine someone uses the same password and username on a site that gets hacked and that can be leveraged to get access to your system to make unlimited calls). Assume that you are making yourself a target, assume that you WILL get a breach and how you will minimise it, and work from there.

Andrew … I did contact the developer and let them know about VoipBl, but they never asked why it was important.

Adding a firewall is a good thing … but my testing showed it fell down in real world testing and might just give an illusion of security (although everything helps).

There is a great danger that small users will assume that because they have the firewall module they are safe without:
Good logging (and looking at your logs occasionally)
Good password policies
Call logs
Call charge limits
etc etc.

I would hope that the firewall module as it develops could include a link to a best practice document about how to secure your system, and remind users that it is just part of a larger picture.

Here’s what I do:

  1. I Don’t forward ANY ports from your NAT router to your PBX.
  2. I set-up IPTables to restrict access from anyone on my network to only the ports that they need to access, i.e.

UDP ports 5060 and 10000-20000 for IP addresses belonging to phones
TCP ports 22 and 80 for an administrator at a single IP address
Additional ports for specific IPs if I want to allow users to access the web-interfaces or use WebRTC.

  1. Remote access via OpenVPN, and not PPTP.

Thanks you all for getting on a more constructive line of dialog, a lot more can be accomplished by doing such.

Graham, I’ll reiterate as mentioned from a previous post that blacklisting is a good component to an overall perimeter defense, and as I mentioned it has not been left ignored and in fact there has been several discussions over the last 1-2 months about what you’ve discussed wrt to aggragating attacks from many systems. I personally don’t know the deails of how/where the VoIPBL project positions their servers to detect and find the offending IPs to blacklist to have any opinion as to how comprehensive and geographically relevant their sources are.

I have followed some of the fraud trends in the VoIP space ot know that attacks are getting more subtle and clever by attackers in the ways some of them initially do very quiet recon to find their victims which will usually go undetected by any of the various means, followed by their eventual targetted attacks which, if they come from a known blacklisted server would of course be blocked, or if was all concentrated from a single source would also get blocked fairly quickly but neither of these is always the case. As such, all forms of detecting and blocking have merit, and a readiness to track the trends and adapt is also important and what we would like to do going forward.