anti-defacement

defacement attacks are usually executed by exploiting either Cross-Site Scripting (XSS) or Remote Code Execution (RCE) attacks - both can be detected and blocked by ASM. In other words - in order to deface a website the hackers first have to exploit a vulnerability hack into your web application / web server and replace the website contents in CMS or upload and change files on the webserver.

Fortiweb offering a specific anti-defacement services by monitoring the contents of the website - this is not really practical for many modern web applications as the website content changes all the time, however in ASM you can use Data Guard to monitor data leakage for specific keywords to achieve extra monitoring and blocking for defacement (provided hackers manage to break into your website protected by F5 ASM WAF)

Hi Samstep,

Basically their Anti Web Defacement prevents all changes from Web servers either it is from a trusted(Developers) or untrusted. If someone changes it, Fortiweb have a backup of all files in the folder it is protecting and restore it the original state. If a developer needs to change or update the webserver, Fortiweb can allow changes for specific timeframe and blocks it again when it expires.

I believe F5 doesn’t have this kind of feature, but I think we should focus on what AntiWeb Defacement of Fortiweb resolves and what is the equivalent process of F5 to achieve the same goal. Can you suggest what can be our approach on this?

Hi,

You may get hash of each individual landing pages and apply iRule something like following to see if the page in response has the same hash before sending it over to the client.

var HASH = hash of the original page

when HTTP_RESPONSE {

if {[class match [b64encode [CRYPTO::hash -alg sha384 [HTTP::header]]] equals HASH ]}

{

   }

else

HTTP::collect

reject

}