Security notice: Open recordings web directory

[mflorell]

I saw this posted today on Twitter, a scanning website has added a new plugin for finding "Vicidial instances exposing recordings"
https://twitter.com/search?q=vicidial&s ... ick&f=live

We do of course suggest at the very least password-protecting your recordings web directory to protect it.

[jamiemurray]

I had a thought about this some time ago, I had intended to create a php download handler that would handle the request to access a recording but perform user auth against vicidial before spitting the file out but never got around to doing it.
This would give the benefit of being able to completely remove the recordings folder from public view. Quickest way I could think of doing this without having to re-do all the existing scripts that touch recordings, is to use a rewrite condition to intercept the file access via /RECORDINGS/MP3, pass it to download.php for authorization and spit the file out if all goes ok, otherwise log the failed authentication like a failed user login.

Any suggestions or ideas? I'm thinking quick but solid fix that could potentially become the default with minimal dev work required. Any reason a similar solution hasn't already been implemented?

[jamiemurray]

I gave it a try, it's working a treat on one of my test boxes. I've uploaded what I did on mantis.

http://www.vicidial.org/VICIDIALmantis/view.php?id=1386

Recordings are only accessible with valid vicidial login and modify leads permission. I thought about it after, it would need to be added to QC users too but the basics are there to get started

[mflorell]

We actually added the System Setting for "Log Recording Access" years ago with a PHP passthru for indirectly downloading recordings(recording_log_redirect.php). As for the default directory permissions, we'll have to look into the best way to add that on the dialers.

[jamiemurray]

I just posted a correction on mantis, I realized afterwards that the htaccess is deleting automatically.
It's now in the apache config for vicirecord

The benefit of this is that it doesn't affect any other user interface things, the existing links are fine, apache handles picking the request up and redirects it to the php script to authenticate the request before the file is returned. I have a few clients where they entirely work remotely (often from dynamic IPs) and locking the recordings folder down or further complicating the process by implementing apache authentication on the folder would just create a support headache for us, so having the permissions based on their user access with no visible changes to the interface or the process they access the recordings is a win-win for us. Functionality remains as is but security is improved.

[jamiemurray]

I also just added the ability for QC users to access recordings.

[njr]

We actually added the System Setting for "Log Recording Access" years ago with a PHP passthru for indirectly downloading recordings(recording_log_redirect.php). As for the default directory permissions, we'll have to look into the best way to add that on the dialers.

Was any progress made on this? This is the most recent result I found searching the forum. Our install, done by the VICIdial team, has open-to-anyone recording directories. I would like to lock them down, but am unsure what that might break. Is it safe to make them inaccessible outside of the local network, or put them behind a password?

Thanks

[mflorell]

We will usually just manually add password protection to the recordings web directory, but this can break some automated functions on the back-end, like any exporting of recordings that may be set up.

[Op3r]

the best way to secure anything vicidial without breaking anything is :

iptables whitelist.

This have saved my ass every pci, vapt, security audit.