When visiting the control panel using google chrome I receive the following message instead of the panel loading up. Possible attack detected. This action has been logged. Prior to posting this I believed it was related to other such postings with this message for ISPC but it appears to not be the case, for this reason a new post is warranted. In the previous post I outlined what I did to reproduce and was able to isolate the issue to just one browser: Chromium Version 73.0.3683.75 (Official Build) Built on Ubuntu , running on Ubuntu 18.04 (64-bit): No issue Firefox Quantum 66.0.2 (64bit): No issue Google Chrome Version 73.0.3683.86 (Official Build) (64-bit): Issue present This leads me to believe that a recent chrome update has changed something that ispconfig relies as you will note, chromium which chrome is based off is an earlier version and does not have this issue. Steps to track down the error. Ensure warnings are being logged > system > server config > [logging : warning] Visit control panel in: Google Chrome Version 73.0.3683.86 (Official Build) (64-bit) View system log: Monitor > select server > system log (No logs for this issue found) The lack of logging is concerning as It means I cannot offer any information to track this issue or what might be causing it. Chrome dev tools shed no light either, all I can suggest now is looking at chrome changelog which I would not know what im looking for in this instance. Chrom(e|ium) change log: https://chromium.googlesource.com/chromium/src/+log/73.0.3683.75..73.0.3683.86?pretty=fuller&n=10000
I use a chrome version which is even newer than yours and don't have any problems: Chrome 74.0.3729.40 The problem might be a session which contains something that triggers the IDS. Try to ddelete cookies in the browser and if this does not help, try to empty the session database table in the dbispconfig database.
We came to the same conclusion on the cookies after i found the following in the system state log (i was looking in server state (foolish icon here): Code: [INTERFACE]: PHP IDS Alert.Total impact: 32<br/> Affected tags: sqli, id, lfi, xss, csrf, rfe<br/> <br/> Variable: COOKIE.amplitude_id_omitted_com | Value: omitted=<br/> Impact: 32 | Tags: sqli, id, lfi, xss, csrf, rfe<br/> Description: Detects classic SQL injection probings 2/2 | Tags: sqli, id, lfi | ID 43<br/> Description: Detects basic SQL authentication bypass attempts 2/3 | Tags: sqli, id, lfi | ID 45<br/> Description: Detects basic SQL authentication bypass attempts 3/3 | Tags: sqli, id, lfi | ID 46<br/> Description: Detects MySQL comment-/space-obfuscated injections and backtick termination | Tags: sqli, id | ID 57<br/> Description: Detects unknown attack vectors based on PHPIDS Centrifuge detection | Tags: xss, csrf, id, rfe, lfi | ID 67<br/> <br/> Im sure those html breaks were meant to break in the log but they just display, thats a small issue, not sure whats causing this cookie error to occur, how it came about that the cookie got broken but it seems resolved by clearing cookies. I suspect difficulty in tracing the cause might be ahead. UPDATE:: I just recalled, its because of the hostname in previous changes as found in my other posts: I changed the hostname to allow LE4ISPC to work on the server as it was not the correct hostname for the panel so could not get a cert for it only a domain cert. the cookies were the old ones but for some reason only now being used. I dont know, All i know is Im now going to have to update that post.
That's not a cookie or cookie value from ispconfig. I guess you might have used another software on the server hostname which has set this cookie and when your browser sends that cookie value to ispconfig, it triggered the IDS. In any case, it's good that the IDS triggered in that case as ISPConfig cookies never contain html tags.
I don't recall using amplitude but having looked into what it is, user tracking, its probably due to a recent change to my website rather than the hostname change. Whats odd is still that the cookie came for the sub domain rather than just the ispc cookie which is only the phpsession currently. Thats not a matter for here, Im going to dig into this because if there is a module im using thats breaking ispc then i dont care what its benefits are it will be gone. From my websites perspective there is no reason modules should be setting such a generic cookie as to be allowing it to get passed to ispc, i don't actually use subdomains for my primary website only for ispc, maybe i need to look into that and fix that with another server (off topic). In any case as this is not actually an ISPC issue I will apologise for wasting your time spent on this, but I also thank you for your assistance, its very much appreciated that you were able to spotlight the issue for me.
