Permit IP Being Ignored

Is there an Asterisk exploit that somehow bypasses the ACL for a SIP peer? I put in 1.1.1.1/255.255.255.255 until I know what their real IP address is. I applied it in FreePBX and even restarted the Asterisk service. There’s still a peer from another IP address in one of the extensions.

I rebooted it, no difference.

I checked /etc/asterisk/sip_additional.conf to make sure it was making it to the configuration and it is.

Which version of FreePBX and Asterisk are you using?

Also, can you please post a screenshot of how you configured it?

FreePBX 12.0.76.6
Asterisk (Ver. 11.4.0)Royal%20Extension%20109%20Permit%20-%20Deny

Check for anonymous connections in your Advanced Settings. You can also look through the /var/log/asterisk/full log file and see how they are connecting. That might also give you some clues on what else to look at.

In SIP settings, “Allow Anonymous Inbound SIP Calls” is set to no.

[root@[redacted] mhammett]# grep -rnw /var/log/asterisk -e ‘C-00005c41’
/var/log/asterisk/full:2311:[2019-07-08 08:13:41] VERBOSE[2373][C-00005c41] netsock2.c: == Using SIP RTP TOS bits 184
/var/log/asterisk/full:2312:[2019-07-08 08:13:41] VERBOSE[2373][C-00005c41] netsock2.c: == Using SIP RTP CoS mark 5
/var/log/asterisk/full:2313:[2019-07-08 08:13:41] VERBOSE[14252][C-00005c41] pbx.c: – Executing [011972599527138@from-internal:1] Macro(“SIP/109-00000313”, “user-callerid,LIMIT,EXTERNAL,”) in new stack

I didn’t see anything that would indicate how they were able to bypass the permit filter and dial out on this extension. I do have other extensions that do have functional ACLs.

Add a deny all statement

deny=0.0.0.0/0.0.0.0

the later permit will also be honored

1 Like

BINGO! It was the only extension that didn’t have the deny statement.

I know it’s resolved.

However, it’s time to make a upgrade plan…

I’m upgrading to a different platform once the customer okays the move.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.