UTM Vulnerable to clickjacking

Ok, so I completely pulled this apart over the last 24 hours and worked out that i was / the tool I'm using is wrong. 

BOTH are vulnerable to clickjacking and found a better tool to actually test it https://clickjacker.io/ 

So I'm back at square one which is that I need the WAF module to be able to inject one of those options in the headers. 
The login form will offer some limited protection to one of our applications but we have a couple things that pass to embedded webservers that we can't modify

So I guess this comes down to how can we do custom apache config to add those headers at the CLI through an inclusions line? 
There is a good summary of fixes here https://clickjacker.io/how-to-fix-clickjacking 

Or if anyone has any other ideas I would really appreciate them 

Ok, so I completely pulled this apart over the last 24 hours and worked out that i was / the tool I'm using is wrong. 

BOTH are vulnerable to clickjacking and found a better tool to actually test it https://clickjacker.io/ 

So I'm back at square one which is that I need the WAF module to be able to inject one of those options in the headers. 
The login form will offer some limited protection to one of our applications but we have a couple things that pass to embedded webservers that we can't modify

So I guess this comes down to how can we do custom apache config to add those headers at the CLI through an inclusions line? 
There is a good summary of fixes here https://clickjacker.io/how-to-fix-clickjacking 

Or if anyone has any other ideas I would really appreciate them 

Ok, found it after stitching together multiple other threads on the topic. 

Firstly: THIS IS NOT A SUPPORTED CONFIG FROM SOPHOS. YOU DO SO AT YOUR OWN RISK. 
Secondly: THIS IS NOT A SUPPORTED CONFIG. You will be making backend changes and if you don't know what you are doing, bail out now
Thirdly: It is likely to be reset upon a webUI change, firmware upgrade or reboot of the device. You will need to recheck on both of these conditions to ensure it remains in place

Also, just because you patch the Sophos unit doesn't solve your issue. These headers also need to be set on the backend servers (aka the "real webservers"). 

Take a backup of your ENTIRE config before proceeding. 

Edit: /var/storage/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf 
Under each VHost you want to fix, find this line: RequestHeader set X-Forwarded-Proto https

Directly under that line without amending it, add these lines:
Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "frame-ancestors 'none'"

Save the file

Restart the service by running:     /var/mdw/scripts/reverseproxy restart

You can also insert the lines to  /var/storage/chroot-reverseproxy/usr/apache/conf/httpd.conf  to do global protection if you were so keen. 

Retest your config to ensure everything works as expected

????

Profit! / Go to the pub

Just realized you're new here.  Your first thread and you have the class to share what you worked hard alone to discover.  

Glad to have you here in the UTM Community!

Cheers - Bob