Changes to external profile requiring Access Control

[smn]

Does anyone know the github commit # that made this change? I am assuming it is in 4.4 because that is the behavior I see on latest stable (4.4).

Just trying to make sure I fully understand it. So by default now, all carriers (gateways) need their IP's added to Access Control. Does not matter external or internal profile. User/Pass or IP authentication. Is that correct?

What would be the setting to change this default so that it allows anonymous on external profile again like before? Is it Advanced > SIP Profiles > External > auth-calls = false? Besides blocking on iptables, is there any other way to prevent anonymous scans from showing up in CDR without requiring auth-calls=true on external profile?

If the default now is to require carriers be added to Access Control, would it make sense to have a feature in Accounts > Gateways that does that automatically when you configure a gateway? I am a big believer in making things simpler to use and I see a lot of opportunities to do that on FusionPBX. I could probably write the code myself if people think it's a good idea.

 

[mingus]

I've been using FusionPBX since 4.2 and it required the use of the Access Control List on the external profile by default even back then.

I highly recommend keeping and using the security measures that are turned on by default in FusionPBX. The FusionPBX defaults are there to keep unauthorized calls from occurring on your switch by default. So you can whitelist entire networks by adding their IP Address Range in CIDR format as a node to the appropriate Access Control List (ACL). If the client making a request isn't ALLOWED in the ACL, the client must then authenticate via SIP Digest Authentication.

Why does it make sense to put it in the ACL rather than the gateway? Two main reasons. The first reason is that Gateways and ACLs are two different systems that aren't necessarily associated with each other. I may use a gateway for just outbound traffic and I may not want to give them permission to send inbound traffic. Conversely, I may allow inbound traffic from a trusted network but send outbound traffic via a gateway pointing somewhere else. In this case, I need the ACL set but not the gateway.

The second reason is for management. It's generally easier to see all your ACLs organized in one logical place rather than multiple places based on context.

To answer your second question, each SIP Profile uses the "apply-inbound-acl" variable to determine which ACL to use. The "internal" and "external" SIP Profiles in a default FusionPBX configuration have the variable set to "domains".

The ACL lists allow you to set default permissions (I highly suggest DENY ALL as default) that are then modified per IP Address or fully qualified domain name with a correct reverse DNS record. To allow anonymous calls, you could just set the default action in the "domains" ACL to "ALLOW" rather than "DENY". I highly recommend against allowing "anonymous" calls through your switch.

If your intent is to control access only through IPTABLES, then that may work for your instance. However, IPTABLES will not scale without a fair amount of effort.

Finally, blocking SIP scanning is a cat and mouse game. The best way to avoid being scanned is to lock down your system to only trusted networks using an external firewall. However, even locking it down to know networks is not full proof. You are still subject to UDP attacks using the spoofed IP address used by any provider you allow inbound traffic from.

Ultimately, SIP scanning is a cat and mouse game. A few strategies include:

• String pattern matching using IPTABLES
• Fail2Ban Rules
• Using non-standard ports for SIP
• Using a combination of all the above.

I hope this helps.

 

[markjcrane]

mingus, giving a point to you for a good answer.

 

[smn]

Someone on the IRC channel said it was changed less than a year ago. Unless it was backported to 4.2.

It was not insecure before. It was just that bot scanners would show up in CDR. More of an annoyance. The whole point of external SIP profile is to allow anonymous. So this kind of goes against that. I'm not opposed to the idea. But it might make sense to have IP's automatically added to ACL when you add a gateway now. It can be an option in the gateway settings. Does not need to be default.

There should at least be a message there that says something like "btw, this will not work until you add the carriers IP to ACL". There should be notes in the user manual as well. I think it would save people from a lot of head scratching. Unless you use this every day you will not know about this. It is not intuitive the way it is now imo.

 

[mingus]

Dealing with an IP Softswitch can be incredibly complicated- interoperability, NAT, fault tolerance, performance, security, etc. I also wish it were easier and more intuitive. However, what is intuitive or obvious for you within the scope of your implementation would likely be folly for me and my implementation. The best practice is to err on the side of caution.

Additionally, many providers will have a set of devices that take traffic and another set of devices that send traffic to your switch. For instance, your gateway may send traffic to 123.123.123.123 but that same provider may deliver traffic to your switch from 5 other IP addresses. In this common scenario, automatically adding the gateway IP address to an ACL just increases your exposure without any additional purpose or benefit.

I hope this helps. Best of luck.

 

[smn]

Dealing with an IP Softswitch can be incredibly complicated- interoperability, NAT, fault tolerance, performance, security, etc. I also wish it were easier and more intuitive. However, what is intuitive or obvious for you within the scope of your implementation would likely be folly for me and my implementation. The best practice is to err on the side of caution.

Additionally, many providers will have a set of devices that take traffic and another set of devices that send traffic to your switch. For instance, your gateway may send traffic to 123.123.123.123 but that same provider may deliver traffic to your switch from 5 other IP addresses. In this common scenario, automatically adding the gateway IP address to an ACL just increases your exposure without any additional purpose or benefit.

I hope this helps. Best of luck.

There is a lot of documentation out there that assumes you do not need to add anything to the ACL. Like this document for example. It makes no mention of needing to add their IP to the ACL, so it was obviously tested on a version that did not have the changes even though it looks like it has been recently updated.
https://support.telnyx.com/articles/1130714-how-to-configure-a-fusion-pbx-user-pass-trunk

I wasted a couple hours trying to figure out why it didn't work. When I found out that it was missing the part about adding the IP to the ACL I wanted to find out why. That is when I found out that it was a change to a default. But it's not really documented anywhere. You basically just have to know about it. It is not a conclusion I intuitively arrived at and there should be some way for that to happen. Either for the GUI to lead you in that direction somehow, or clearly mentioning it in the documentation. It's mentioned, but it doesn't specifically say that it is a mandatory thing now.

 

[DigitalDaz]

The reason you will not see it in most guides is because it is completely turning upside down the Freeswitch method of handling this.

The entire reasoning of the external profile is that it IS unauthenticated. No carrier is going to authenticate to you to send calls. In my opinion this is a misuse of the logic because what it does is switch on authentication for the external profile despite the fact that you are still not using it. What you are instead doing is adding the carriers to the ACL so you can BYPASS what you have just enabled, ie auth.

Its like installing a turnstile at a football games that uses swipe cards to let people in but instead of that ever letting anyone in, they instead have a side gate that anyone on the A-List goes through.

A far superior way is to use iptables to control access to the external profile, something I have argued for since the introduction of this. It is far more efficient and effective.

 

[smn]

The reason you will not see it in most guides is because it is completely turning upside down the Freeswitch method of handling this.

The entire reasoning of the external profile is that it IS unauthenticated. No carrier is going to authenticate to you to send calls. In my opinion this is a misuse of the logic because what it does is switch on authentication for the external profile despite the fact that you are still not using it. What you are instead doing is adding the carriers to the ACL so you can BYPASS what you have just enabled, ie auth.

Its like installing a turnstile at a football games that uses swipe cards to let people in but instead of that ever letting anyone in, they instead have a side gate that anyone on the A-List goes through.

A far superior way is to use iptables to control access to the external profile, something I have argued for since the introduction of this. It is far more efficient and effective.

I am not opposed to the idea, if gateways were automatically added to the ACL when external profile is selected. Maybe a required field in gateway settings. So it forces the user to enter an ACL CIDR. If you don't want to do that for whatever reason there could be a checkmark and default setting to disable that.

I would like to try avoid having to do it in iptables if at all possible.

 

[DigitalDaz]

The biggest problem I see with the ACL method is that it still allows you to get loaded up with things like invite DOS attacks. If they do not supply a password there is nothing to ban and the attacks will come on hammering in with Freeswitch having to take care of them. Adding gateways to an ACL automatically wouldn't have much relevance as all but the smallest providers will be sending from multiple IP addresses.

 

[mingus]

The FusionPBX ACL is set up by default to deny anonymous traffic through the switch on the external SIP profile. If the inbound network isn't on the ALLOWED list, the system falls back to digest authentication. The benefit of using the ACL is that you save the digest authentication costs on incoming traffic from ALLOWED networks.

I agree that IPTABLES works better at filtering traffic but only when all of your devices are on fixed networks. I can't see how we can achieve the same security and flexibility for customers on dynamic networks using IPTABLES.

DDOS attempts seem to be unavoidable regardless of ACLs or IPTABLES. I've chased that rabbit through many holes. The best I've been able to do is mitigate the attempts using a combination of connection limits, fail2ban, and pattern matching.

 

[smn]

If someone wants to flood you nowadays, I don't think there is much you can do on the server. Today's floods would simply overwhelm the connection 100x over. Not to be confused with bot scanners which do load things down and can be mitigated.

 

[DigitalDaz]

I agree that IPTABLES works better at filtering traffic but only when all of your devices are on fixed networks. I can't see how we can achieve the same security and flexibility for customers on dynamic networks using IPTABLES.

I'm clearly missing something here. How exactly does the ACL work then with dynamic networks??

 

[mingus]

By dynamic, I mean a network with a non-static public IP address and/or range. By fixed, I mean a network with a static public IP address and/or range.

It's not so much that ACL's help with dynamic networks as much as it helps reduce the computational cost of authentication coming from a high traffic source like inbound calls from the underlying carrier.

If you are exclusively using IPTABLES to filter traffic, you can block all SIP traffic and ACCEPT SIP traffic from networks that you know because they are fixed networks. However, if the public IP address were to change (as it does with dynamic networks), the network will be blocked until you update the IPTABLES.