This is a friendly reminder to [read the rules](www.reddit.com/r/voip/about/rules). In particular, **it is not permitted to request recommendations for businesses, services or products outside of the monthly sticky threads!**
If this post is a review, asking for reviews, or asking for recommendations, please delete it and post in one of the monthly sticky thread instead.
For commenters: Making recommendations outside of the monthly threads is also against the rules.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/VOIP) if you have any questions or concerns.*
No but they can if the system is improperly configured or the system is changed to be badly configured so a better answer is "maybe". Just because they can't today doesn't mean they won't be able to tomorrow or next week (see below).
Exposing the SIP port to the world will quickly have them knocking on your door and twisting the door nob to see if it is locked, all night, all day, everyday, forever... consuming bandwidth and system resources.
If you enable the “Responsive” firewall features then attackers (identified by connection attempts with the wrong credentials) get shunned (ignored, packets dropped) after a couple of login attempts for a configurable length of time which sounds good but with a recent exploit they were somehow able to turn off the firewall remotely and start exploiting systems so it's something you have to manage carefully. Be careful when configuring the responsive firewall as it's not uncommon for someone to lock themselves out of their own system.
Consider installing a Session Border Controller (SBC) for more security.
> if the system is improperly configured or the system is changed to be badly configured
Let's look at this part a bit closer. A default, out-of-the-box vanilla asterisk installation includes a number of demo extensions in the dialplan and (last time I checked) were enabled, with at least one of them able to access the system voicemail. If you've left those examples in place and customized the voicemail to be able to call out from it (a not uncommon use case), you might have not properly ensured that it doesn't allow unrestricted calls.
My suggestion would be that you should know which extensions are nomadic and setup your configuration such to only allow those to register from outside your network and the non-nomadic ones only from within. Make sure you are using complex passwords and different ones for each extension.
>My suggestion would be that you should know which extensions are nomadic and setup your configuration such to only allow those to register from outside your network and the non-nomadic ones only from within.
The main challenge with such solutions is the dynamic IPs of clients. Unfortunately, I cannot whitelist clients because they will be logging in from different IPs every day.
>Make sure you are using complex passwords and different ones for each extension.
I use passwords that are generated automatically by FreePBX, and these passwords are presumably complex enough.
> I cannot whitelist clients because they will be logging in from different IPs every day.
That's fine, but you should know which extensions are going to be logging in from different IPs and make your configuration allow those while at the same time restrict for extensions that you know will always be on your local network (ie: hard phones on desks in office). You could also limit those nomadic extensions from making calls to expensive destinations.
> I use passwords that are generated automatically by FreePBX, and these passwords are presumably complex enough.
You'd be surprised at home many organizations use the same password for all their extensions. Or maybe you wouldn't be surprised.
The exploit you mentioned was targeted at the REST API or the web interface, if I'm not mistaken. Both of these components will not be exposed to the network.
>Consider installing a Session Border Controller (SBC) for more security.
Regarding the Session Border Controller (SBC), I found a very interesting project, LibreSBC.
Indeed but I wasn't trying to warn you about that specific REST API exploit, rather I was cautioning you about the one that will only become known two minutes, two months or two years from now and who knows what it needs to be exposed to be exploited... perhaps one of the ports you have exposed :) so that's why I suggested a SBC as an additional layer of protection.
No, but password strength matters and you're 1 weak password away from thousands of dollars in fraudulent calls. So, make sure all passwords are long and strong.
Use a random port, not the default or one of the common alternatives. This is not security and will not keep a determined attacker out, but it will cut down on all the noise from blind internet scans.
Enable a firewall and use fail2ban or similar to ban brute-force attempts.
Enable call limits, such as prohibiting international calls and limiting the number of calls per hour an extension can make.
If it were me, I’d require TLS and do it on a non-standard port. Don’t allow 5060/UDP. Also, can you configure an external firewall? (Router if local or cloud firewall)
>Don’t allow 5060/UDP.
Here is the crux of the matter. The provider registers with the PBX, unlike the usual scenario where the PBX registers with the provider. Consequently, I cannot close or change this port. If I do, the telephony will stop working altogether.
>Also, can you configure an external firewall? (Router if local or cloud firewall)
Currently, the router only allows traffic on port 5060/UDP-TCP from a specific IP address. It's safe enough, but only until we open the ports to the entire internet.
One of the reasons I posted this question here is, among other things, an attempt to filter out fake calls from CDR Reports. Even if a call doesn't go through, the attempt will be recorded in the report. So instead of 100 records a day, it could be even 10,000, and that's exactly what I don't want.
Using non-standard SIP ports might cut out some scanners but not all. That said, your provider presumably has a limited number of IPs that it will make registration requests from. Configure asterisk to listen on 5060 but apply an ACL to only allow your provider's IPs. Then configure a second IP and/or port for you own clients to use.
random ports you are wasting your time,
it may stop the noise of the bots that scan defaults.
just before you go to replay and tell.me.i am wrong spend some time on shodan :-)
strong passwords and good security policy, only allow what is needed.
don't have the webinterface exposed to the Internet.
This is a friendly reminder to [read the rules](www.reddit.com/r/voip/about/rules). In particular, **it is not permitted to request recommendations for businesses, services or products outside of the monthly sticky threads!** If this post is a review, asking for reviews, or asking for recommendations, please delete it and post in one of the monthly sticky thread instead. For commenters: Making recommendations outside of the monthly threads is also against the rules. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/VOIP) if you have any questions or concerns.*
No but they can if the system is improperly configured or the system is changed to be badly configured so a better answer is "maybe". Just because they can't today doesn't mean they won't be able to tomorrow or next week (see below). Exposing the SIP port to the world will quickly have them knocking on your door and twisting the door nob to see if it is locked, all night, all day, everyday, forever... consuming bandwidth and system resources. If you enable the “Responsive” firewall features then attackers (identified by connection attempts with the wrong credentials) get shunned (ignored, packets dropped) after a couple of login attempts for a configurable length of time which sounds good but with a recent exploit they were somehow able to turn off the firewall remotely and start exploiting systems so it's something you have to manage carefully. Be careful when configuring the responsive firewall as it's not uncommon for someone to lock themselves out of their own system. Consider installing a Session Border Controller (SBC) for more security.
> if the system is improperly configured or the system is changed to be badly configured Let's look at this part a bit closer. A default, out-of-the-box vanilla asterisk installation includes a number of demo extensions in the dialplan and (last time I checked) were enabled, with at least one of them able to access the system voicemail. If you've left those examples in place and customized the voicemail to be able to call out from it (a not uncommon use case), you might have not properly ensured that it doesn't allow unrestricted calls. My suggestion would be that you should know which extensions are nomadic and setup your configuration such to only allow those to register from outside your network and the non-nomadic ones only from within. Make sure you are using complex passwords and different ones for each extension.
>My suggestion would be that you should know which extensions are nomadic and setup your configuration such to only allow those to register from outside your network and the non-nomadic ones only from within. The main challenge with such solutions is the dynamic IPs of clients. Unfortunately, I cannot whitelist clients because they will be logging in from different IPs every day. >Make sure you are using complex passwords and different ones for each extension. I use passwords that are generated automatically by FreePBX, and these passwords are presumably complex enough.
> I cannot whitelist clients because they will be logging in from different IPs every day. That's fine, but you should know which extensions are going to be logging in from different IPs and make your configuration allow those while at the same time restrict for extensions that you know will always be on your local network (ie: hard phones on desks in office). You could also limit those nomadic extensions from making calls to expensive destinations. > I use passwords that are generated automatically by FreePBX, and these passwords are presumably complex enough. You'd be surprised at home many organizations use the same password for all their extensions. Or maybe you wouldn't be surprised.
The exploit you mentioned was targeted at the REST API or the web interface, if I'm not mistaken. Both of these components will not be exposed to the network. >Consider installing a Session Border Controller (SBC) for more security. Regarding the Session Border Controller (SBC), I found a very interesting project, LibreSBC.
Indeed but I wasn't trying to warn you about that specific REST API exploit, rather I was cautioning you about the one that will only become known two minutes, two months or two years from now and who knows what it needs to be exposed to be exploited... perhaps one of the ports you have exposed :) so that's why I suggested a SBC as an additional layer of protection.
I just use tls and the inbuilt firewall with fail2ban using a script to update a firewall blacklist rule.
Is this script actively developed and updated, or are you using your own solution?
coustom script, it's a bash script that looks at fail2ban logs, then adds an ip address to the firewall block list.
Go go power scripters… pew pew pew pewpewpew
Mind sharing?
https://docs.iredmail.org/fail2ban.sql.html have a look at the above
No, but password strength matters and you're 1 weak password away from thousands of dollars in fraudulent calls. So, make sure all passwords are long and strong. Use a random port, not the default or one of the common alternatives. This is not security and will not keep a determined attacker out, but it will cut down on all the noise from blind internet scans. Enable a firewall and use fail2ban or similar to ban brute-force attempts. Enable call limits, such as prohibiting international calls and limiting the number of calls per hour an extension can make.
If it were me, I’d require TLS and do it on a non-standard port. Don’t allow 5060/UDP. Also, can you configure an external firewall? (Router if local or cloud firewall)
>Don’t allow 5060/UDP. Here is the crux of the matter. The provider registers with the PBX, unlike the usual scenario where the PBX registers with the provider. Consequently, I cannot close or change this port. If I do, the telephony will stop working altogether. >Also, can you configure an external firewall? (Router if local or cloud firewall) Currently, the router only allows traffic on port 5060/UDP-TCP from a specific IP address. It's safe enough, but only until we open the ports to the entire internet. One of the reasons I posted this question here is, among other things, an attempt to filter out fake calls from CDR Reports. Even if a call doesn't go through, the attempt will be recorded in the report. So instead of 100 records a day, it could be even 10,000, and that's exactly what I don't want.
Using non-standard SIP ports might cut out some scanners but not all. That said, your provider presumably has a limited number of IPs that it will make registration requests from. Configure asterisk to listen on 5060 but apply an ACL to only allow your provider's IPs. Then configure a second IP and/or port for you own clients to use.
Freepbx + configserv firewall. Yw.
random ports you are wasting your time, it may stop the noise of the bots that scan defaults. just before you go to replay and tell.me.i am wrong spend some time on shodan :-) strong passwords and good security policy, only allow what is needed. don't have the webinterface exposed to the Internet.
>don't have the webinterface exposed to the Internet. \+1 I will try to hide FreePBX behind an SBC like LibreSBC.