Hello, i am using latest debian 11 and latest ispconfig. All working fine, i did updated all the time. Today i have a problem - can not access to ispconfig - i have installed it more then 1 year and never had the problem. In ispconfig i get blank page with Possible attack detected. This action has been logged. What does it mean, how can i found why this happened? I found this https://forum.howtoforge.com/thread...k-detected-this-action-has-been-logged.78605/ ant i will try it But i need to found out why this is happened.Any ideas?
Most likely you run a website or web-based software on the exact same domain as the ISPConfig GUI and this other software sets cookies which then get sent to ISPConfig when you access ISPConfig and ISPConfig has not set the cookies itself. You can find exact details in the ISPConfig monitor module in ISPConfig's system log.
Thank you. Yes, i have ispconfig on the exact same domain as the ISPConfig. But how is possible? The same sites without any changes etc with the ispconfig on the same domain i have more than 1 year and everything working fine. I have this problem first time today. in ispconfig log i can see this log. Code: [INTERFACE]: PHP IDS Alert.Total impact: 20<br/> Affected tags: xss, csrf, rfe<br/> <br/> Variable: COOKIE.__gads | Value: ID=0441122160ad3503-22cfc233e2cd009b:T=1659539185:RT=1659539185:S=ALNI_MYioN9RO_kvO60vmYFs-ZGH-VxaKA<br/> Impact: 10 | Tags: xss, csrf, rfe<br/> Description: Detects JavaScript location/document property access and window access obfuscation | Tags: xss, csrf | ID 23<br/> Description: Detects data: URL injections, VBS injections and common URI schemes | Tags: xss, rfe | ID 27<br/> <br/> Variable: COOKIE.__gpi | Value: UID=00000b74634aab63:T=1665993604:RT=1665993604:S=ALNI_MYNfCEVzDYe34kY1tfYrWqxwuHJ9w<br/> Impact: 10 | Tags: xss, csrf, rfe<br/> Description: Detects JavaScript location/document property access and window access obfuscation | Tags: xss, csrf | ID 23<br/> Description: Detects data: URL injections, VBS injections and common URI schemes | Tags: xss, rfe | ID 27<br/> <br/>
Seems to be a cookie from Google: https://cookiedatabase.org/cookie/google-various-services/__gpi/ If I remember correctly, I read somewhere that Google started to insert cookies under the name of the website now these days. There is a file /usr/local/ispconfig/security/ids.whitelist which can be used to whitelist certain variables, but you can't create a wildcard whitelist item at the moment to whitelist __gads globally for all pages. I will see if I can add an option for that as probably more users will experience that in future that use Google services.
Ok, the following should work (not tested yet). Edit these two lines in the ids class: https://git.ispconfig.org/ispconfig/ispconfig3/-/merge_requests/1639/diffs Then add the following line at the end of the /usr/local/ispconfig/security/ids.whitelist file: Code: any:*:COOKIE.__gpi this should whitelist this cookie for all login levels in all files of ISPConfig.
This "Possible attack detected. This action has been logged." is serious issue because i got logic like this client has domain.com -- the panel is on subdomain.domain.com so it will be good to make fixes in next update because it is making too much trouble... i know that we need to secure with IDS but this is not working as expected. Also possibility to create whitelist.
This is working perfectly fine and as expected in ISPConfig 3.2.9p1 and it is not causing any issues, especially no serious issues, on properly set-up systems. Plus you know already how to fix it if your system was not set up in the right way, see post #6. You have two options now: 1) Fix your system setup so that other software does not try to inject cookies into ISPConfig, which triggers the IDS warning. This means the software you run on domain.com must set its cookies for domain.com only and not other subdomains. So this is not related to ISPConfig. It's simply a wrong setup in the software you installed on domain.com 2) If you do not want or are able to fix your setup or the software on domain.com does not allow you to set up cookies properly for domain.com only, then you can do what I described in post #6. The code change you highlighted has already been included in ISPConfig btw. So you might have missed keeping your system up to date if its not on your server yet. And there can not be another fix besides the two options I mentioned above, so asking us to make changes in ISPConfig makes not much sense as one can either detect cookie injections and react to them or whitelist the offending cookie as described in #6. There is a third option of course, disable IDS completely, but that#s not a good option as you mentioned yourself. That's exactly what's described in post #6 in this thread and available in the current ISPConfig release.
