Blog

The recommended method for locking down Vicidial is to allow only whitelisted IP addresses access through the firewall. 

However, the call center I contract for has a lot of "at home" agents with dynamic IP addresses.  Updating the whitelist manually became a difficult task as more agents with dynamic IP addresses came online. They needed a way to automate the process of updating the whitelist on the pfSense firewall in real time. I investigated several options, and decided that creating my own solution was the best route.

I manage several Vicidial setups for this client, including a couple of stand-alone dialers and a cluster. So for simplicity, I put all of the servers behind a pfSense firewall.  I chose this route because it gives me the ability to manage security from a single point for their entire network. 

First I looked to pfSense for a solution. Built into pfSense is a handy way update an Alias list using a web hook. I thought great!, this is the perfect solution… I can create an Alias called "Whitelist" and apply it to the rules for the Vicidial servers.

The problem was, that the web hook method for updating the Alias list is only triggered by pfSense once a day.  I investigated manually changing the cron to run at a much shorter interval, but decided to scrap that approach as it would have to run every minute or so to allow "instant" access for agents whose IP addresses changed.  I also didn't want to muck around too much with the code base, opening up the potential to make it difficult to apply updates later.  

Another approach was to use the "Dynamic Good Guys Whitelist Firewall" for Vicidial. This method utilizes the IP tables already present on the vicidial server.  However to implement this solution I would have to move the servers from behind pfSense and out to the public internet.  

I didn't like this approach for two reasons: 

1. It required moving and reconfiguring the servers to work on the public IP.  

2. It decentralized the firewall management to each individual server.  

After reading up on pfSense I discovered it uses one master configuration file, config.xml.  The config.xml file lives in the /conf/config.xml directory.

With that knowledge in hand here was my plan:  
1. Create an authentication gateway in ColdFusion for the at home agents to log into. The gateway would detect their IP address, and if it was different it would trigger a process to update the whitelist on pfSense.  
2. Once a new IP was detected, run a CF script that would get the config.xml file from the firewall, update it, place it back on the firewall and flush the old config to update the firewall tables. 

Simple, right?   Here are the details on configuring pfSense to work with Putty from the Windows CMD line. 

Step 1. Install Putty and create a saved session to the firewall.  I named mine “firewall”.

Step 2. Download Plink (A command line interface to Putty).

Step 3. Log into your pfSense web GUI and make sure you have SSH enabled. 

The setting is located in the System > Advanced menu. 

Step 4. Putty into pfSense as root and create the following .sh files in the /conf directory.

putconfig.sh - Sends the config.xml file to the ColdFusion server via FTP

getconfig.sh - Retrieves the config.xml file from the ColdFusion server

resettables.sh - Reloads the pfSense firewall rules

Step 5. Set the permission of the new files to allow 'root' to execute them. 

# chmod 755 putconfig.sh

# chmod 755 getconfig.sh

# chmod 755 resettables.sh
When you're done, type # ls -la to list the /conf directory... it should look like this:    

Step 6. Test the setup by running a ColdFusion <cfexecute> command to Plink and see if the config.xml file is FTP'ed to the CF server.

<cfexecute name="C:\WINDOWS\system32\cmd.exe"
     arguments="/c C:\plink.exe -v root@firewall  -pw MyPassword /cf/conf/putconfig.sh"
     timeout="5">
</cfexecute> 

Here is the ColdFusion code I used to make the calls to pfSense and update the conf.xml file. 

The application has been up and running for a little over a year and to date we have never had an instance where we needed to roll back the firewall config.