Question
How to disable WebShield for a domain?
Is there a way to exclude certain subscription, customer, or resellers from WebShield?
Answer
It is possible to whitelist a domain using the following command:
# imunify360-agent whitelist domain add example.com
The CAPTCHA/SplashScreen will be skipped for the whitelisted domains.
In order to enable back:
# imunify360-agent whitelist domain delete example.com
Comments
5 comments
Currently, it is not possible to whitelist not a whole domain but only a specific URL for visiting by bots.
It should additionally be possible to disable captcha for a domain on my server so that remote requests to an API do not trigger the captcha
There are some mechanisms that might be involved here.
First, if an IP is in Gray list, a request to the server will be blocked by CAPTCHA. The CAPTCHA challenge will be skipped for the whitelisted domain.
To this Gray list, IPs are added after local rules triggering and when certain limits are reached. Graylisting has progressive TTLs, but will be released after TTL has expired. Addresses also added from the Imunify360 servers based on data from our global heuristics. For example, if one IP was spotted many times attacking servers and not being able to pass CAPTCHA.
In this regard, it is worth noting that False Positives often happens when 3d party vendors for WAF rule sets are used. It is recommended to disable those.
Nonetheless, there are other mechanisms and lists.
It is also the case that a request might be blocked by some specific WAFs if this IP is in one of our RBLs. This is a Realtime Blackhole List to block attackers without updating rules, these are used by modsec (and partially PAM) to block without grey listing.
Imunify has several different RBL zones such as "web-spammers", "infectors", "risky-actions", "wplogin-www-brute", etc. Depending on the suspicious activity that has been detected for an IP address, it appears in the corresponding RBL sublists.
It is important to mention that there are only a couple of ModSecurity RBL based rules that can be triggered by requests to wp-login.php or xmlrpc.php, this means that other pages of a website will be accessible for RBLed IP. In this regard, it is needed to make sure API is not hosted on those URLs.
If this is the case, it is required to whitelist the IP and to disable the RBL protection for it with the following command:
Finally, if legitimate requests to the server are restricted by the anti-bot protection page with a message as follows:
SplashScreen can be disabled:
Events & Incidents lookup can help you to define what list or rule was applied:
https://blog.imunify360.com/events-and-incidents-lookup-feature
Thanks for the detailed update. However none of these conditions apply in my case.
Modify this file to add javascript or css files for your page from customize/static folder
Jinja2 (which is index.html template engine) is not allowed to use here." Given that there is a spelling mistake tempalte it should be easy to find which page is being displayed.
Thank you for asking! It is our pleasure to clarify the articles and provide you with more accurate information.
Regarding the tempalte typo, this seems like a curious finding and requires us to inspect this in place, if you would be willing to provide us with access.
We can't disagree on that. This is the benefit of using a well-tuned system with a predefined set of rules with close to zero false-positives. Sorry for the inconveniences. The hypothesis should not be applied to this particular case. Also, it was clarified that the remote requests weren't blocked by our RBL subnet,
As of now, it is presumed that there might be 3d party software that Intervene with Imunify360 logic, and we would like to gather more details on this case.
This case is getting more relevant to a specific combination of factors involved rather than the article above, as such, we would prefer to move it to further support via tickets format if you allow us to do this.
Thank you!
Please sign in to leave a comment.