Use the Web Application Firewall (WAF)
To manage the Web Application Firewal, go on the administration interface in Web > Sites > site details > WAF menu.
|Basic||Force strict HTTP protocol
HTTP Detect malicious bots
Detect Remote Code Execution (RCE)
Detect Cross-Site Scripting (XSS) attacks
Detect SQL Injections
Detect attacks for PHP language
Detect attacks by Remote File Injection (RFI)
A WordPress’ specific ruleset
A Drupal’ specific ruleset
Depending on your use case, the WAF's behavior may be too restrictive . It also can generate false positives during its analysis. If you think its behavior is not right, it is possible to exclude certain rules normally used during the analysis.
Only the ID of the rules to exclude have to be specified. You will find it in the Sites logs (~/admin/logs/sites). Example:
[08/Jan/2019:11:09:19 +0100] [waf] - <IP d'attaque> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941100 | XSS Attack Detected via libinjection' with value: "><script>alert(1);</script> [08/Jan/2019:11:09:19 +0100] [waf] - <IP d'attaque> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941110 | XSS Filter - Category 1: Script Tag Vector' with value: <script> [08/Jan/2019:11:09:19 +0100] [waf] - <IP d'attaque> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941160 | NoScript XSS InjectionChecker: HTML Injection' with value: <script>
941100, 941110 and 941160 might be indicated.
CAUTION: it is necessary to gradually add rules as the exclusion is applicable throughout the site. Indeed, even if adding a large number of rules to exclude can improve navigation in some cases, the protection will be reduced in all other cases.
This exclusion type allows to avoid the analysis of webpages starting by the specified path. By enter
/foo/ by example, www.mon-site.com/foo/ will be excluded from the analysis as query strings: www.mon-site.com/foo/?param=bar. To also exclude www.mon-site.com/foo/bar and www.mon-site.com/foo/script.php, you have to add a wildcard:
/foo/*. At last, if we want to substitute any character (especially any that constantly change)
? can be used.
So to rule out the analysis www.mon-site.com/whatever/fooT/, whatever and T being any character, the path to exclude will be:
Example: let's take the cas of a WordPress website which has similar logs as those presented earlier. If these rules are activated in the blog administration interface, it is possible to permanently exclude them.
However the blog will not be protected against these attempted attacks. In this case, it is wise to exclude the path (example: /wp-admin/*) : all operations in the administration interface won't be affected by the WAF analysis.
Exclude safe IPs may be worthwhile to prevent to some tools or people from being blocked.
Take WPScan as example: by activating it on a WordPress website some of the requests it carries out may be blocked. Paths or rules exclusions would not be efficient as it examines numerous URLs. The solution will be to exclude the HTTP server on which WPScan is installed. It will then be able to operate normally.