Blog Knowledge Base Security Uncategorized

GDPR and Call recordings

The effects of the GDPR on call recording will be to further strengthen the rights of individuals when it comes to businesses collecting, recording and using their personal data, placing greater onus the business to demonstrate compliance & increasing the penalties for not doing so.

All of this will have a direct impact on how you manage call recording. We will ask try to explain what the changes will be, what you need to know, and what you can do to get ready.

The Law As it Was

Previously, call recording was classified as a form of data processing. The Data Protection Act states that individuals must be informed and aware that they are being recorded and why they are being recorded.

This is because recorded calls have the ability to capture:

  • Personally identifiable information such as, names and addresses
  • Sensitive information such as, banking, financial, health, family, religious etc. detailsThe Data Protection Act also, sets outs rules for the correct handling of data, which requires any calls recorded to be stored securely with steps to be taken to avoid breaches.

So the main principles behind the GDPR are quite similar to those that were in place within UK legislation. With regards to call recording, the key principles are the expectation to protect privacy, notification and consent, and the requirement to adequately protect stored data from misuse.

The main difference with the GDPR will be that it strengthens the rights of the individual over the rights of an organisation. The DPA focuses on balancing the interests of individuals and businesses – as long as steps to protect privacy are followed, collecting and recording personal data is generally assumed to be justified.

Not so under the GDPR. Businesses wishing to record calls will be required to actively justify legality, by demonstrating the purpose fulfils any of six conditions:

  1. The people involved in the call have given consent to be recorded.
  2. A recording of a call is necessary for the fulfilment of a contract.
  3. Recording is necessary for fulfilling a legal requirement.
  4. The call recording is necessary to protect the interests of one or more participants
  5. The call recording is in the public interest or necessary for the exercise of official authority.
  6. Recording is in the legitimate interests of the recorder, unless those interests are overridden by the interests of the participant in the call.

Some of these conditions will apply specifically to certain uses of call recording in certain sectors. Number three, for example, could be used by firms in the financial services sector, which are required by the FCA to record all calls leading up to transactions. Number five will apply to the emergency and security services, who use call recording for investigatory purposes and in the interests of public protection.

But for general call recording, for example to monitor service levels or for staff training in a contact centre, the options left to businesses will be numbers one or six. And as the ‘legitimate interests’ of a business to evaluate customer service are not likely to outweigh the interests of personal privacy under the new regulations, so that only leaves gaining consent.

So unlike the previous law, assumed consent will not be satisfactory. With the GDPR strengthened rights of individuals to know what is happening with their personal information and to restrict and object to what happens to it, explicit consent to record calls will be required.


Along with the new GDPR comes a new ‘Principle of Accountability’ which puts a requirement on organisations to demonstrate their compliance. Data protection policies will soon become a statutory compliance document, rather than a recommended option. Therefore, businesses wishing to record calls will be required by law to draw up a specific call recording policy.

Next Step

So what to do, carry out a thorough audit of call recording practices, from the notifications given to how recordings are stored, is the first step to take. This should be done in the context of a wider evaluation of data protection, taking into account factors like how data breaches are identified, impact assessments and training and awareness within the business. From there, policies and protocols can begin to be drawn up, giving you plenty of time to make sure you hit the ground running come May 2018.

ICO Views on file retention and encryption

Data controllers must consider the security of lawful recordings and whether this can be achieved through the use of full-disk or file encryption products. However, some types of audio recording devices such as a dictation machines may not routinely offer encryption. The data controller must consider whether an alternative device is more appropriate or consider additional technical and organisational safeguards such as deleting the data as soon as practicable and locking the device away when not in use.

In the event that an unencrypted version of the recording should be retained (eg for playback in a Court of Law) then a range of other compensatory measures must be considered. These can include storage within a secure facility, limited and authorised access and an audit trail of ownership and usage.

The data controller must also consider the security of recordings once transferred from the device for long-term storage and be aware of other requirements which may prohibit audio recording of certain types of data.

Asterisk Support Knowledge Base Security

Catching the IP of anonymous callers on Asterisk servers

Hi just sharing a simple bit of dialplan to catch anon callers ip addresses when using freepbx and Anonymous callers is set to yes, which is needed for some suppliers.

Normally I would say lock your firewall to only known IPs, but in some cases this isn’t possible

Im sure if you have a Asterisk server with a public IP you will have seen calls on the console screen where the call is to a destination but the callers are exten@yourserver . Well this little bit of dialplan at the end of you default sip context should catch them and log them with the ip of the originating server

In extensions_custom.conf add the dialplan below

exten => s,1,Noop(Dead calls rising)
exten => s,n,Set(uri=${SIPCHANINFO(uri)})
exten => s,n,Verbose(3,Unknown call from ${uri} to ${EXTEN})
exten => s,n,System(echo "[${STRFTIME(${EPOCH},,%b %d %H:%M:%S)}] SECURITY[] Unknown Call from ${CALLERIDNUM} to ${FROM_DID} IPdetails ${uri}" >> /var/log/asterisk/sipsec.log)
exten => s,n,Hangup()

Then in Custom Destinations add a destination as  catchall,s,1

so you now get in your logs

[May 1 00:11:06] SECURITY[] Unknown Call from  to 900441516014742 IPdetails sip:101@

 I hope this is some help to you, It allows other scripts to pick up this address and add it to your firewall.
Elastix Support Security

SSLv3 Poodle and Elastix

Google has just disclosed SSL POODLE vulnerability which is a design flaw in SSLv3.  By default SSLv3 is enabled by default in Elastix and many other servers, Since it is a design flaw in the protocol itself and not an implementation bug, there will be no patches. Only way to mitigate this is to disable SSLv3 in your web server or application using SSL.

How to test for SSL POODLE vulnerability?

The following simple script will test, its a re-write of Redhats that would give a false negative if the script fails in anyway giving a false sense of security.

chmod 755 /usr/share/doc/bash-3.2/scripts/timeout
ret=$(echo Q | /usr/share/doc/bash-3.2/scripts/timeout 5 openssl s_client -connect "${2-443}" -ssl3)
if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then
 if echo "${ret}" | grep -q 'Cipher.*0000'; then
 echo "SSL 3.0 disabled"
 echo "SSL 3.0 enabled"
 echo "SSL disabled or other error"

The outputs will be similar to below on Elastix

[root@elastix24 ~]# ./ 
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
verify error:num=10:certificate has expired
notAfter=Jun 15 18:30:20 2014 GMT
verify return:1
depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
notAfter=Jun 15 18:30:20 2014 GMT
verify return:1
SSL 3.0 enabled

As we can see its enabled.

Now edit the file  /etc/httpd/conf.d/ssl.conf

and change line 100 (in Elastix 2.4)

from SLProtocol all -SSLv2    to  SLProtocol all -SSLv2 -SSLv3

The restart the httpd service.

then test again and you should get

13033:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1086:SSL alert number 40
13033:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:
SSL disabled or other error

If you want to read the background here is the relevant document

Click to access ssl-poodle.pdf

Asterisk Support Elastix Support Knowledge Base Security

Elastix 2.4 ARI vulnerability Patch

The recent vulnerability in the Asterisk and Freepbx ARI login.php file is not addressed in an update to ARI in the unembedded freepbx on Elastix 2.4.

This will mean that your systems will still be vulnerable.

We have produced a patch that you can apply to address this. The patch can be downloaded  from and applied as detailed below.

logon to the server console

cd /var/www/html/recordings/includes
cp login.php /root/login.php.ari
patch < ari.patch 

Then to check either login to server ARI interface or 

cat login.php |grep json

and you should get the following output

$buf = json_decode($_COOKIE['ari_auth'],true);
$data = json_decode($crypt->decrypt($data,$ARI_CRYPT_PASSWORD),true);
$data = $crypt->encrypt(json_encode($data),$ARI_CRYPT_PASSWORD);
$buf = json_encode(array($data,$chksum));

also check to see if you have the file in the fw_ari directory.

ls -l /var/www/html/admin/modules/fw_ari/htdocs_ari/includes

if there is a login.php there then copy over the patched version.

cp /var/www/html/recordings/includes/login.php  /var/www/html/admin/modules/fw_ari/htdocs_ari/includes/login.php

After these actions check that the file ownership is still correct

if not 

chown asterisk:asterisk /var/www/html/recordings/includes/login.php 

This patch also applies to any older version of ARI out there.

also to be on the lookout for two suspicious files, named “” or “” respectively. If you see these two files remove them immediately!

More details here. or here




Asterisk Support Blog Elastix Support Knowledge Base Security

Shellshocked by Bash !

Well any one in IT and many people who never have anything todo with dirty working of *nix operating systems including Apples OSX cant have missed the news about the latest venerability. This is hot on the heels of teh OpenSSl one and the NTP one before that.

All these have different levels of risk, The NTP one was just a pain easily fixed and could cause little damage, The Openssl one was more of a risk as it allowed hackers to read the memory of systems using certain versions of OpenSSL nicknamed Heartbleed. Now the Bash one is fairly simple to exploit and has been now seen in the wild which in the case of Heartbleed it wasn’t really exploited in the wild.

So how do you test. simple , just type

env x='() { :;}; echo vulnerable’ bash -c “test”

and if it comes back saying Vulnerable update bash.

Great easy you say, well it was spent half a day checking 40 odd servers and updating bash. But then the update they rolled out want enough so today went back round updating again.

It has to be noted that some repositories were running slow and in teh case of one (SCHMOOZE) they hadn’t got the latest patch live by mid day.

It was pleasing how most suppliers were open and concise on what to check and how to fix. I was rather disappointed with  another Asterisk Based PBX distro who instead of publishing how to check and what to do, told users to download a script and run that, I don’t think its a good idea to hide security measures, If people deploy systems they need to know how to secure them.

I wonder whats next? , After spending 2 days on this now looking at setting up a Puppet server, This has cost me a day of my time and i’m meant to be installing a queuemetrics call center for a customer…

Knowledge Base Security

Remote ssh tunnel script

We have various customers that have firewalls that only allow known trusted IP addresses through. Normally our office and our monitoring platform for example.

But if we are out and about we still sometimes need to access a system and its GUI, so we have created the simple script below that makes a ssh connection to the customer server and also tunnel to access any web gui.

This script is in place on the monitoring server so we can just ssh in to the monitoring platform and run the script. all that is needed is a single tunnel setup on the ssh client that i’m accessing the monitoring platform from.

echo ssh tunnel tool. 2013
echo Setting up a tunnel to $1
whois $1 |grep netname
if [ "$1" = '' ]; then
 echo "You have no remote destination set"
 echo "usage: <remote server> <remote ssh port> <remote system port>"
 echo "For example 8022 80"
if [ "$3" = '' ]; then
echo "usage: <remote server> <remote ssh port> <remote system port>"
echo "For example 8022 80"
if [ "$2" = '' ]; then
 echo "You have no remote ssh or system port set, Setting ssh to port 22"
 echo "You have no remote system port set, Setting remote to port 80"
if [ "$port" = '' ]; then
echo Remote system IP is $1
echo Remote ssh port is $port
echo Remote system port is $rport
read -p "Is this correct? (y/n) " RESP
if [ "$RESP" = "y" ]; then
 echo "Glad to hear it"
ssh -L 9999:localhost:$rport  $1 -oport=$port
Asterisk Support Elastix Support Knowledge Base Security

Keeping the Bots at bay out and allowing your friends in

Recently we have seen an upsurge in Bots attacking Asterisk servers, Interestingly its not good old sipvicious anymore but a Windows program called sipcli and originating mainly from the US and Germany.

Normally our iptables firewalls are updated but for some reason these keep getting through, So we have now based rules on the User-Agent in iptables as well

Here are a few examples to get rid of many of the favourites

-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipcli" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP

Also its worth adding these ranges as little good will ever come from them

# Ponytelecom ranges

-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP 
-A INPUT -s -p udp -j DROP

For Freepbx format add following to /etc/firewall-4.rules

-A fpbxreject -s  -m udp -p udp -j DROP
-A fpbxreject -s   -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s  -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP
-A fpbxreject -s -p udp -j DROP

If you are still getting problems check out a sip trace and look for the contact part of the

Contact: <sip:100@xxx.www.rrr.zzz:5070>
Max-Forwards: 70
User-Agent: sipcli/v1.8                       <<<<<<<<<<<<<<<< here it is 
Content-Type: application/sdp
Below is a simple Bash script to create iptables entry for Linux. Create a script and paste the code in , if you just run it it created entries ready for Centos iptables id you run  ‘scriptname freepbx’ it created the entry for /etc/firewall-4.rules
SCANNERS='owenee Custom SIP gazllove pplsip sipcli sipvicious sip-scan sipsak sundayddr friendly-scanner iWar CSipSimple SIVuS Gulp sipv smap friendly-request VaxIPUserAgent VaxSIPUserAgent siparmyknife Test'
if [ "$SYS" != "freepbx" ]
echo This is for a $SYS system
echo Copy and paste below
PROTOS='udp tcp'
for scanner in $SCANNERS; do
for port in $PORTS; do
for proto in $PROTOS; do
if [ "$SYS" = "freepbx" ]
echo -A fpbxreject -p $proto -m $proto --dport $port -m string --string '"User-Agent:' $scanner'"' --algo bm --to 65535 -j DROP
echo -A INPUT -p $proto -m $proto --dport $port -m string --string '"User-Agent:' $scanner'"' --algo bm --to 65535 -j DROP

In this case just set as we have in iptables and it will catch all versions.

Hope this helps you as much as it has helped us

Also this idea can be reversed to only allow user agents (phones) you want to accept.

Here are a few examples of common soft and hardphones

-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Yealink" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: FPBX" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Linphone" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: DX800" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: 3CX" --algo bm --to 65535 -j ACCEPT
-A ELASTIX_INPUT  -p udp -m udp --dport 5060 -m string --string "User-Agent: Grand" --algo bm --to 65535 -j ACCEPT

Again to find others just do a sip trace and note down the user agent.

This can also be extended to make you system more secure by only allowing in devices that register to you FQDN and not just ip address

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
# -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#ssh moved from 22 to random port
-A INPUT -m state --state NEW -m tcp -p tcp --dport 65432 -j ACCEPT
#Web interface moved to new port.
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8765 -j ACCEPT
#drop sipvicious traffic
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A INPUT -i eth0 -p udp --dport 5060 -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p udp --dport 4569 -m state --state ESTABLISHED,RELATED -j ACCEPT
#only allow Yealink phones
-A ELASTIX_INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: Yealink" --algo bm --to 65535 -j ACCEPT
#That register to your domain name directly
-A INPUT -i eth0 -p udp --dport 5060 -m string --string "REGISTER" --algo bm -j ACCEPT 
#only allow iax from known server
-A INPUT -s -p udp -m udp --dport 4569 -j ACCEPT
-A INPUT -i eth0 -p udp --dport 5060 -j DROP
-A INPUT -i eth0 -p udp --dport 10000:20000 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

The above example should keep you secure. (but things and methods change so keep your eye on the ball)