UTM Vulnerable to clickjacking

Hi vAdmin,

Thanks for reaching out to the Community! 

I would suggest you check if there's any DNAT rule for the service/port that got detected in the scan. 

Thanks,

No DNAT on the UTM and I can see that the UTM is responding as there are the other headers added by the UTM present 

In both instances it is acting as a WAF only. 

Hi and welcome to the UTM Community!

Standard questions:  On the one working correctly, do you see the block in the WAF log or in the Intrusion Prevention log?  Have you tried restoring a recent config backup on the bad guy? Have you tried re-booting?

Cheers - Bob

There is no block happening, and that is the problem. 

I have not tried a reboot or a config restoration. I did restart apache however, no dice. 

Where is the block in the unit that behaves correctly?  This will be a clue to avoid the following...

My usual suggestion would be to try the following, in order, on the misbehaving unit until the problem disappears:

1. Restore a config backup.
2. Reboot.
3. Re-image from ISO and restore.

Any luck with that?

Cheers - Bob

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