Please read this carefully as it contains important information regarding the security of your VICIdial system.
The ViciDial Group recently conducted a security audit of VICIdial which resulted in the identification of severe vulnerabilities. We have patched these and submitted these changes to the code-base. Any system that is at SVN version 3848 or greater already has them. If your system is below that version, we strongly recommend that you upgrade to address these concerns. If you would like us to upgrade your system for you, please send a new email to support@cyburdial.com and put “Security Upgrade” in the subject. A typical upgrade takes about 15 to 30 minutes of support time. You can see the seriousness of these exploit here: https://packetstormsecurity.com/files/181461/VICIdial-2.14-917a-Remote-Code-Execution.html https://packetstormsecurity.com/files/181460/VICIdial-2.14-917a-SQL-Injection.html
To find the SVN version of your VICIdial installation, log into your administator account and go to “Admin”, then click on “System Settings”. It will be the second line from the top, on the right, under “SVN Version”.
Please note, if your setup contains customizations done directly to VICIdial’s code, further review of your system will be needed as it may not be possible to upgrade you.
There is a new security vulnerability in ViciDial for SVN versions 3754 and below. These are labeled as severe and need to be addressed immediately if you are below SVN 3755. You can do so by following this article: How to – Update your Vicidial version with subversion.
This short post is just going to briefly go over the more common commands you need in order to manage firewalld and make sure you keep your servers safe. This firewall works in conjunction with the dynamic portal for ViciDial as well as the built in whitelist initially named ViciWhite in the IP list area in Admin.
Dynamic portal
Systemctl and Firewalld
Enable firewalld
This makes sure that firewalld will be started automatically with the server.
systemctl enable firewalld
Start firewalld
After the firewalld service is enabled, you’ll need to start it manually the first time. This is how you would manually start firewalld if it were not already running.
systemctl start firewalld
Stop firewalld
When troubleshooting rules and connection issues, you may need to stop the fireawlld service momentarily. You can stop the service with the following command.
systemctl stop firewalld
Restart firewalld
If for some reason, you need to restart the service, you can do that with the systemctl restart command.
systemctl restart firewalld
Firewalld status
Checking the status of the service gives us the most meaningful and informative output. Here you can see whether the service is enabled, running, failed, or anything else.
systemctl status firewalld
In this example output, you can see that the service is enabled, active, and running on the server. If it were not running or in a failed state, this would be displayed.
[root@alma ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-01-22 22:50:32 EST; 1h 0min ago Main PID: 808 (firewalld) CGroup: /system.slice/firewalld.service └─808 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
Managing Firewalld and Configuring Rules
Now that we have firewalld running, we can get down to set the configuration. We can open ports, allow services, whitelist IPs for access, and more. In all of these examples, we include the –permanent flag. This is important to make sure a rule is saved even after you restart firewalld, or reboot the server. Once you’re done adding new rules, you need to reload the firewall to make the new rules active.
Add a Port for TCP or UDP
You do have to specify TCP or UDP and to open a port for both. You will need to add rules for each protocol.
Using a slight variation on the above structure, you can remove a currently open port, effectively closing off that port.
firewall-cmd --permanent --remove-port=444/tcp
Add a Service
These services assume the default ports configured within the /etc/services configuration file; if you wish to use a service on a non-standard port, you will have to open the specific port, as in the example above.
You can also allow a range of IPs using what is called CIDR notation. CIDR is outside the scope of this article but is a shorthand that can be used for noting ranges of IP addresses.
As the firewall-cmd tool is mostly used for opening or allowing access, rich rules are needed to block an IP. Rich rules are similar in form to the way iptables rules are written.
Whitelist an IP Address for a Specific Port (More Rich Rules)
We have to reach back to iptables and create another rich rule; however, we are using the accept statement at the end to allow the IP access, rather than reject its access.
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'
Removing a Rich Rule
To remove a rich rule, use the option —remove-rich-rule, but you have to fully specify which rule is being removed, so it is best to copy and paste the full rule, rather than try to type it all out from memory.
firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept'
Saving Firewall Rules
After you have completed all the additions and subtraction of rules, you need to reload the firewall rules to make them active. To do this, you again use the firewall-cmd tool but using the option –reload.
firewall-cmd --reload
Viewing Firewall Rules
After reloading the rules, you can confirm if the new rules are in place correctly with the following.
firewall-cmd --list-all
Here is an example output from the –list-all option, you can see that this server has a number of ports, and services open in the firewall along with a rich rule (that forwards one port to another).
Hopefully this will help a lot of you that end up just not using a firewall at all because it intimidates you not knowing how to use it correctly. Well, I’ve just eliminated that excuse, so now I want to see more of you securing your servers and dialer systems. Here is a few articles to get you started in the right direction.
That’s it for this article, hopefully you guys take this serious because hackers, especially ransomware thieves are targeting dialer servers in particular for their schemes, such as using the VoIP to call their victims to either trick them into downloading files or threatening them over the phone with blackmail or other means. BazarCall is one of the more well known tools thats being used by the ransomware group called Ryuk.
The ViciDial Group has released a warning for any SVN version below 3583, if you are below this version, update your system immediately. You can do so by following this article for SVN update.
ViciDial versions below 3583 are Vulnerable!
I hope everyone takes this seriously, or your data may be hacked or minutes used on your VoIP, or worse.
I am carpenox from the Vicidial forums and I enjoy helping our community, of which I do free of charge, however my one on one time helping people out I do have to charge for my time in order to keep this going. If my articles have helped you out and you’re making money now because of my help, please think about donating to the cause so I can keep this blog going. Here is a link to donate through PayPal.
