Does the Purify ad blocker for iOS still get updates?

TL;DR – The app still works but the block list has not been updated since 2018-10-20.

I’ve had the Purify App installed on my iOS devices since it was originally released and have recently been wondering if it still worked. The last version update for the App was 2018-09-21 which honestly is probably fine since blocking content in a web browser is probably a solved problem at this point and all that really matters is that the block list itself is being updated.

When you launch Purify on your device and click ‘Update Now’ it appears to be checking and pulling the latest block list right? I had assumed so.

Today I decided to check. I grabbed a copy of mitmproxy, installed it’s SSL certificate on a test device and started poking around. Here is what I found.

When you click the ‘Update Now’ button the App reaches out to: https://www.purify-app.com/app-services/latest-version?1667683942.93690300313600ACFB

The first number (1667683942) is a Unix timestamp for right now. I have no idea what the second number and characters (93690300313600ACFB) is for. It changes every time I click ‘Update Now’.

Either way you don’t need either value to view the contents of https://www.purify-app.com/app-services/latest-version which is just a text file named “latest-version” that contains a number (105 as of this writing).

The number 105 signifies the latest revision of the block list Purify uses. If you already have this version download the Purify App does nothing further.

Using mitmproxy I was able to intercept and alter the response from the web server so that it returned “106” instead of “105” which triggered the App into thinking there was a new block list to download. I then had what I was after which was the URL of the block list itself.

The 105 version of the block list can be found here: https://www.purify-app.com/app-services/blockerList.105.json

If you change 105 to 104 you’ll get a previous version of the block list.

Checking the headers on the web request I found the “last-modified” stated “Sat, 20 Oct 2018 17:35:43 GMT”.

Mozilla says:

The Last-Modified response HTTP header contains a date and time when the origin server believes the resource was last modified.

This leads me to believe the block list for Purify hasn’t been updated since 2018-10-20 making the App fairly useless at this point despite likely still functioning.

Before publishing this blog post I reached out to the author for comment but heard nothing back after waiting a week.

If you’ve somehow stumbled across this blog post before purchasing Purify, I’d recommend spending your $1.99 elsewhere. It’s a little disappointing the developer hasn’t pulled the App from the store where it can still be purchased or published anything on the official Website or Twitter feed stating the block list is no longer being updated.

Do I have a recommendation for an alternative? Not an iOS App specifically. I use a PiHole personally.

How to use CIRA Canadian Shield with a Pi-Hole and DoH

CIRA (Canadian Internet Registration Authority) has recently launched a new DNS service called the “Canadian Shield” which is basically a DNS service similar to OpenDNS or Cloudflares 1.1.1.1 for Canadians, by Canadians.

CIRA offers three levels of protection depending on how safe you want to be:

  • Private: DNS resolution service that keeps your DNS data private from third-parties.
  • Protected: Includes Private features and adds malware and phishing blocking.
  • Family: Includes Protected and Private features and blocks pornographic content.

We use the Enterprise version of this service at my place of work and based on how we use it I’d say we’re using the equivalent of their “Protected” offering. We’ve had zero issues with the service and defiantly feels like it adds an extra layer or protection to our users.

Alright, enough free advertising (I am not receiving compensation from CIRA for this post).

When this was first announced I was eager to try it at home. CIRA’s instructions are how to either configure DNS over HTTPS (DoH) on a per-browser basis (not ideal for me since I have many devices on my network and don’t only use Firefox/Chrome) or configure your outbound DNS to use their servers over traditional, un-encrypted, DNS queries.

What I really want is to configure my Pi-hole which is my DNS endpoint for anything on my network to use the new CIRA service. This would capture ALL outbound DNS traffic and send it to CIRA making it so I only have to configure things in one place.

My current setup is: Clients -> 1 of 2 Active Directory DNS Servers -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

This will easily work on a more traditional deployment of: Clients -> Pi-hole -> Cloudflare via DoH (1.1.1.1 / Cloudfared)

My Pi-hole is a basic CentOS 8 VM with the Pi-hole software installed on it with cloudflared so I can take advantage of DoH for all of my outbound DNS traffic. This is the minimum you need to get this working, a functional Pi-hole that is already sending it’s outbound DNS queries to Cloudflare (or another DoH provider) via cloudflared.

The first thing I did was re-configure my cloudflared to simply try using the CIRA DoH:

# Edit the cloudflared configuration file
vim /etc/default/cloudflared

# Commandline args for cloudflared to use 1.1.1.1
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query

# Changed the above to:
CLOUDFLARED_OPTS=--port 5053 --upstream https://private.canadianshield.cira.ca/dns-query

# Save and close the file

# Restart cloudflared
systemctl restart cloudflared

# Test DNS
nslookup google.ca

# This failed

 

This ended up not working and after I tried it I realized why. To be able to use private.canadianshield.cira.ca you have to have functioning DNS. Cloudflare has skirted this issue by using 1.1.1.1 and 1.0.0.1 for it’s service, they are IPs and do not need DNS to be working to function.

Fortunately the solution was very easy:

# I did a nslookup on the specific CIRA service I wanted to use (Private) via traditional DNS

nslookup private.canadianshield.cira.ca 1.1.1.1

Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   private.canadianshield.cira.ca
Address: 149.112.121.10
Name:   private.canadianshield.cira.ca
Address: 149.112.122.10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bb::10
Name:   private.canadianshield.cira.ca
Address: 2620:10a:80bc::10

# If you want to use Protected or Family instead of private 
# do a nslookup on either protected.canadianshield.cira.ca
# or family.canadianshield.cira.ca instead and use those IPs

# I then edited my /etc/hosts file on my Pi-hole
vim /etc/hosts

# and added the following (I don't use IPv6 at this time):

# CloudA DNS
149.112.121.10 private.canadianshield.cira.ca
149.112.122.10 private.canadianshield.cira.ca

# Save and close the file

# Test DNS
nslookup cira.ca
Server:         192.168.0.4
Address:        192.168.0.4#53

Non-authoritative answer:
Name:   cira.ca
Address: 52.60.203.65

 

That’s it. I now have the CIRA Canadian Shield working on my Pi-hole using the cloudflared software.

Now for some DNS benchmarks, what’s faster? CIRA or 1.1.1.1?

I flushed the DNS cache on my Active Directory DNS servers and then restarted cloudflared on my Pi-hole before running these benchmarks:

1.1.1.1.1 / 1.0.0.1

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.052 | 0.196 | 0.043 | 100.0 |
  + DotCom Lookup | 0.009 | 0.013 | 0.027 | 0.004 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.009 | 0.051 | 0.195 | 0.044 | 100.0 |
  + DotCom Lookup | 0.010 | 0.014 | 0.028 | 0.003 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

and here are the three CIRA services:

CIRA - Private

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver




CIRA - Protected

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.019 | 0.062 | 0.236 | 0.048 | 100.0 |
  + DotCom Lookup | 0.022 | 0.046 | 0.086 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.068 | 0.238 | 0.056 | 100.0 |
  + DotCom Lookup | 0.023 | 0.047 | 0.075 | 0.019 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver



CIRA - Family

  192.168.  0.  4 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.064 | 0.246 | 0.053 | 100.0 |
  + DotCom Lookup | 0.022 | 0.039 | 0.080 | 0.018 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                   CAYENNE.nom.fizi.ca
                Local Network Nameserver


  192.168.  0.  5 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.000 | 0.000 | 0.000 | 100.0 |
  + Uncached Name | 0.014 | 0.073 | 0.248 | 0.062 | 100.0 |
  + DotCom Lookup | 0.024 | 0.049 | 0.082 | 0.020 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                 HORSERADISH.nom.fizi.ca
                Local Network Nameserver

 

If I am interpreting this data correctly, CIRA is 0.010s-0.030s slower on average compared to 1.1.1.1. Hardly worth mentioning.

I’m happily switching over to a Canadian based DoH service (full disclosure, I’m Canadian). No offence Cloudflare, you still get to hold my DNS until CIRA starts offering their DNS Anycast Service for home users (hint hint).

Oh and just in case your curious, if you choose their ‘Family’ service and try and hit up Pornhub, you’re greeted with this:

Accessing a Pi-Hole behind an Apache reverse proxy

Update 2019-09-15: Finally got around to looking into this and it turns out all I had to change was “ProxyPreserveHost Off” to “ProxyPreserveHost  On” to get things working. I’ve updated the original post to reflect the changes. I also didn’t note in my original host that I purposely restricted access to the apache virtual host to 10.0.0.0/24 and 192.168.0.0/24 (my internal networks). You’ll want to update the “Allow from” lines to reflect your internal networks OR remove the “<Location /></Location>” all together to make it accessible from anywhere (not recommended).

Update 2019-08-19: I just recently found out that this proxy configuration only allows read-only access to the Pi-Hole UI. I was attempting to white-list a domain and it was failing when accessing my Pi-Hole via the proxy. I had to go directly to the box’s FQDN to white-list a domain. I will leave this post for reference and update it when I figure out a fix to this problem.

Update 2019-09-29: My first Lets Encrypt certificate came due for auto-renewal and failed because of my original configuration. I’ve updated the apache configuration below so Lets Encrypt can access the non-SSL /.well-known directory to automatically renew certificates.

Original Post

Today I got tired of accessing my Pi-Hole over HTTP, having to remember to put /admin/ in the URL and having to load up a browse that wasn’t Vivaldi or Firefox because they don’t have an easy way to ignore Strict-Transport-Security for my domain.

I checked out some documentation about adding SSL to the Pi-Hole directly but have concerns that future updates will wipe out all the custom configuration to lighttpd. According to this you also have to be careful when enabling SSL on your Pi-Hole as it could interfere with blocking.

I already have an Apache webserver running so configuring it to reverse-proxy seemed like an easier task, plus if for some reason I wanted to access my Pi-Hole from the general internet (without VPN) it would be simple to enable that.

Here is the reverse proxy configuration I used with a restriction to my two internal networks and a redirect from HTTP to HTTPS:

<VirtualHost *:80>
       ServerName pihole.mydomain.com
       DocumentRoot /var/www/html
       CustomLog logs/pihole.mydomain.com.log combined
       ErrorLog logs/pihole.mydomain.com-error.log

	<Location /.well-known>
		Order allow,deny
		Allow from all
	</Location>

	<Location />
		Order deny,allow
		Deny from all
		Allow from 127.0.0.1
		Allow from 192.168.0.0/24
		Allow from 10.0.0.0/24
	</Location>

       RewriteEngine On
       RewriteRule ^(.well-known)($|/) - [L]
       RewriteCond %{SERVER_PORT} 80
       RewriteRule ^(.*)$ https://pihole.mydomain.com/ [R,L]
</VirtualHost>

<VirtualHost *:443>
        ServerName pihole.mydomain.com
        DocumentRoot /var/www/html
        CustomLog logs/pihole.mydomain.com.log combined
        ErrorLog logs/pihole.mydomain.com-error.log

	<Location />
		Order deny,allow
		Deny from all
		Allow from 127.0.0.1
		Allow from 192.168.0.0/24
		Allow from 10.0.0.0/24
	</Location>

        RewriteEngine On
        RewriteRule ^/$ /admin [R]

        # The below line is not required so I have commented it out but left it in place
        # in case I am wrong. I no longer use Apache so I can't test. If this config doesn't
        # work uncomment the below line.
        # ProxyRequests On
        ProxyPass /  http://pihole-internal-hostname.mydomain.com/
        ProxyPassReverse / http://pihole-internal-hostname.mydomain.com/
        ProxyPreserveHost On

        SSLEngine on
        SSLHonorCipherOrder off
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

        SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
        SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

        SSLCertificateFile /etc/letsencrypt/live/pihole.mydomain.com/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/pihole.mydomain.com/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/pihole.mydomain.com/chain.pem
</VirtualHost>

I am aware that my SSL configuration is not the best. I’m waiting for CentOS 8 to come out before migrating off my existing CentOS 6 server.

To find the best SSL configuration for your OS and Web Server I recommend checking out Mozilla’s SSL Configuration Generator: https://ssl-config.mozilla.org/

VeraCrypt CLI Benchmark Script

I was setting up VeraCrypt on a Raspberry Pi 2 the other day so I could use it as a backup target for my main server and was curious how fast, hahaha just kidding, I mean how slow VeraCrypt would be.

To my disappointment VeraCrypt does not provide a method for running the benchmark built into the GUI via the CLI.

This is the nice benchmark you can run from the GUI:

veracryptBenchmark

So I took some time this weekend and wrote a simple BASH script you can use to benchmark the CLI version of VeraCrypt.

I only tested it with VeraCrupt 1.18a. Chances are if you run it with a previous version you’ll get some really fast times for the new Encryption/Hashes they added in 1.18 because the test won’t actually run.

The benchmark I wrote simply outputs how long it takes to create and encrypt a container of a specific size. It’s not quite as good as the GUI version which outputs the actual speed but it’s at least something. I think this will work on any version of Linux. I tried to use only build-in system utilities and since I wrote it on CentOS 6 means I probably used some of the oldest GNU utilities still commonly used.

During my testing I found that having a container size to small would result in all times being nearly the same with the exception of ripemd160 and streebog. To get better results I recommend using at least a 1GB test file size on modern hardware. Even at 1GB you can see the sample from my main server has each encryption and hash type only varying by 2-45 seconds.

Here is a sample of what the script outputs:

I will admit I don’t fully understand these results. I would have expected much more variety in timing between the different types of encryption under a single hash type. Especially on the Raspberry Pi 2.

The script does a simply container creation benchmark in it’s default state. However if you add <USERNAME RUNNING BENCHMARK> ALL=NOPASSWD: <PATH TO bin/veracrypt>  to your sudo file and change FILLCONTAINER=0  to FILLCONTAINER=1  it will perform file write speed benchmark.

and here is the script itself:

#!/bin/bash
# Simple Veracrypt CLI Benchmark Script
# Tested on Veracrypt: v1.18a
#
# Created by: Eric Schewe
# Created on: 2016-09-03
# Version: 1.1
# Last updated: 2016-06-05 16:38
# Source: http://www.pickysysadmin.ca/
#

#Benchmark size in bytes. Uncomment which ever size you'd like to use.
#If you want to add your own sizes make sure they are multiples of 26214400 (25MB)
#CONTAINERSIZE=104857600 #100MB
#CONTAINERSIZE=209715200 #200MB
#CONTAINERSIZE=524288000 #500MB
CONTAINERSIZE=1048576000 #1GB

#This determines if we are going to write data into the containers we create
#You must temporarily alter your sudo file for this to work by adding this line:
#<USERNAME RUNNING BENCHMARK> ALL=NOPASSWD: <PATH TO bin/veracrypt>
#Be sure to remove this line from your sudo file once your completed benchmarking
FILLCONTAINER=1
FILLFILECOUNT=`expr $CONTAINERSIZE / 26214400 - 1`

#All the hashes currently supported by VeraCrypt
HASH=(sha256 sha512 whirlpool ripemd160 streebog)
#All the encryption methods currently supported by VeraCrupt
ENCRYPTION=(AES Twofish Camellia Kuznyechik Serpent Gost89 AES-Twofish AES-Twofish-Serpent Serpent-AES Serpent-Twofish-AES Twofish-Serpent)
#Get the cpu model of the system running the benchmark
CPUINFO=`cat /proc/cpuinfo |grep -oP "model name.*?:(.*)" | uniq |sed "s/model name.*: //"`
#Hostname of system running the benchmark
HOSTNAME=`hostname`
#Start time in a good format (https://xkcd.com/1179/)
STARTTIME=`date "+%Y-%m-%d - %k:%M:%S"`
#And a Unix Timestamp to calculate elapsed time easily
STARTTIMEUNIX=`date +%s`
#Calculate the megabyte size of the container being created
CONTAINERSIZEMB=`echo "$CONTAINERSIZE / 1024 / 1024" |bc`

#For output
LONGHEADER="-------------------------------------------------------------------------------------------------"
SHORTHEADER="-------------------------------------------------------------------"

#Output the benchmark header based on the type of benchmark we are doing
if [ $FILLCONTAINER -eq 1 ];
then
  echo $LONGHEADER
else
  echo $SHORTHEADER
fi
echo "- Veracrypt Benchmark"
echo "- Started: $STARTTIME"
echo "- Hostname: $HOSTNAME"
echo "- CPU: $CPUINFO"
echo "- Container Size: $CONTAINERSIZEMB megabytes"
if [ $FILLCONTAINER -eq 1 ];
then
  echo $LONGHEADER
  printf "%-10s | %-30s | %-15s | %-15s | %-15s \n" "HASH" "ENCRYPTION" "VOL CREATE TIME " "VOL FILL TIME " "SPEED (MB/sec)"
  echo $LONGHEADER
else
  echo $SHORTHEADER
  printf "%-10s | %-30s | %-1s \n" "HASH" "ENCRYPTION" "TIME"
  echo $SHORTHEADER
fi

#Loop through each HASH
for a in "${HASH[@]}"
do

  #Loop through each ENCRYPTION method for this HASH
  for b in "${ENCRYPTION[@]}"
  do
    #Grab a random 320 character string and re-use it for all encryptions done for the current HASH
    < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-320} > randomString.txt 2>&1
    #Grab a random 64 character password (maximum length VeraCrypt supports)
    RANDOMPASSWORD=`< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-64};echo;`
    #General a container name that shouldn't conflict with anything already in the directory
    CONTANIERNAME=`echo -n $RANDOMPASSWORD | md5sum -t |head -c${1:-24}`".vc"

    #Create a VeraCrypt volume and time it, little grep to get the only time we care about from the output
    VOLUMECREATETIME=`(time veracrypt --create $CONTANIERNAME --size=$CONTAINERSIZE --password $RANDOMPASSWORD --encryption $b --hash $a --filesystem FAT --pim=2048 --random-source=randomString.txt --keyfiles= --volume-type=Normal) 2>&1 |grep -i "real" |sed "s/real//" |sed "s/ //g"`

    if [ $FILLCONTAINER -eq 1 ];
    then
      #Figure out the directory name we are going to mount the volume to and then create it
      DIRNAME=`echo -n $RANDOMPASSWORD | md5sum -t |head -c${1:-24}`
      mkdir $DIRNAME
      #Mount the container to the directory we just created
      veracrypt --mount $CONTANIERNAME --hash $a --password=$RANDOMPASSWORD $DIRNAME --pim=2048 --keyfiles= --protect-hidden=no >/dev/null 2>&1
      #Get the start time for filling up the container
      FILLSTARTTIME=`date +%s`
      #Fill the container with 25MB files
      VOLUMEFILLTIME=`(time (for (( i=1; i<=$FILLFILECOUNT; i++ )); do dd if=/dev/urandom of=$DIRNAME/$i".dat" bs=26214400 count=1 status=none conv=fdatasync; done)) 2>&1 |grep -i "real" |sed "s/real//" |sed "s/ //g"`
      #Get the end time for filling up the container
      FILLENDTIME=`date +%s`
      #Math to calculate elapsed seconds and then how many MB/sec we did
      FILLELAPSED=`echo "$FILLENDTIME - $FILLSTARTTIME" |bc`
      FILLSPEED=`echo "scale=3; $FILLFILECOUNT * 26214400 / $FILLELAPSED / 1024 / 1024" |bc -l`
      #Output the results
      printf "%-10s | %-30s | %-15s | %-8s | %-15s \n" "$a" "$b" "$VOLUMECREATETIME" "$VOLUMEFILLTIME" "$FILLSPEED"
      #Umount the container and clean up before the next container is created
      veracrypt -d $CONTANIERNAME >/dev/null 2>&1
      rm -rf $DIRNAME
    else
      printf "%-10s | %-30s | %-1s \n" "$a" "$b" "$VOLUMECREATETIME"
    fi

    #Cleanup before next volume is created
    rm -f $CONTANIERNAME
    rm -f randomString.txt

  done

  #Output a footer to signify the completion of this HASH
  if [ $FILLCONTAINER -eq 1 ];
  then
    echo $LONGHEADER
  else
    echo $SHORTHEADER
  fi
done

#UNIX timestamp when we're all done. Then do some math and conversions
ENDTIMEUNIX=`date +%s`
ELAPSEDTIME=`expr ${ENDTIMEUNIX} - ${STARTTIMEUNIX}`
ELAPSEDTIME=`date [email protected]$ELAPSEDTIME -u +%H:%M:%S`

#Output summary footer
echo "- Completed on `date "+%Y-%m-%d - %k:%M:%S"`"
echo "- Elapsed Time (HH:MM:SS): $ELAPSEDTIME"

if [ $FILLCONTAINER -eq 1 ];
then
  echo $LONGHEADER
else
  echo $SHORTHEADER
fi

I’m not super confident in the output. Some of the numbers leave me scratching my head. It’s completely possible I’ve got something totally wrong with this script. Please feel free to post comments/revisions.

How to block the Skillpages.com contact import App with Symantec Endpoint

(Updated December 11th, 2012 – 9:115 PST)

TL;DR: Turns out there isn’t an easy way to do this with just Symantec and trying to block the Java App. We blocked *@skillpages.com on our gateway anti-spam server and that took care of the problem for the most part.

Original article

We recently experienced a user who signed up for Skillpages.com. Upon signing up they chose to import their Outlook contacts. This causes a Java Application to download to the users workstation and automatically import their Outlook contacts. Big problem for us because it also imported our entire Global Address List from Exchange. Then Skillpages.com spammed our entire organization trying to get more users to sign-up.

Blocking *@skillpages.com on our gateway antispam server (Puremessage) took care of the e-mail spam but we wanted to prevent users from running the Java App in the first place on our workstations.

This will go poorly if the users Outlook is hooked into Exchange and you have a substantial global address book.

Blocking the domain that the Java App is downloaded from might be a bad idea. Cloudfront.net is a redirect to Amazon’s CloudFront service and who knows what amount of legitimate uses there are for it.

Next up was trying to block the Java App as it downloaded. To do this we created a new ‘Application and Device Control’ policy with the following settings:

In a nut shell this policy will monitoring the Java processes for any attempt to write a temporary file that matches the pattern “66c3f8b9-*-temp”. We determined that the first set of characters are static and only the second group change from download to download. After implementing this policy we tried a few random sites with Java on them and didn’t have any problems with legitimate apps being accessed.

In theory this should work until Skillpages.com gets wise and changes the prefix on their Java Applet.

I’m open to better ideas if you have them.

Update – December 10th, 2012 – 12:25 PST

Checked out the results of my brilliant plan today and it looks like the temp file name has changed to ‘577a15c9-72a17cab-temp’. So much for that idea. For now I’ve added the new temp file name to our policy but I don’t think this is going to be a practical solution in the long term.

It seems Symantec can’t block the download itself which is a consistent ‘ContactsFinder.jar’ which comes from “http://dyjab6i3qfxan.cloudfront.net/20121210.6/Resources/Internal/ContactsFinder/ContactsFinder.jar”. We also don’t deploy the firewall component which might make this easier.

Update – December 11th, 2012 – 9:06 PST

So I checked again today and the temp files prefix has one again changed. I don’t think this method of blocking is going to be effective.

If you have Symantec Endpoint and have the firewall installed on your users machines you can probably block the download site directly…  or if you have a Proxy server…. or if you have a modern edge firewall. Try blocking “http://dyjab6i3qfxan.cloudfront.net/20121211.3/Resources/Internal/ContactsFinder/ContactsFinder.jar”

I also finally got an e-mail back from Skillpages after requesting my e-mails be removed since I didn’t consent to them being uploaded. Skillpages instructed me to create an account with each e-mail address (effectively agreeing to their ToS and EULA) and then go to http://www.skillpages.com/i/settings#email and remove my account. Not an acceptable solution in my books.