I've moved ISPConfig to "ispconfig.example.tld", as this is a less ugly and more memorable URL for clients to use (and it just neatly fits in with the other software we offer on our servers, which are also given as subdomains of the main domain). Our main domain - where our primary website resides - is not "www" prefixed. It's just "example.tld" - there's even a rewrite from "www.example.tld" to "example.tld" to force it. As it's kind of a "branding" thing to be "www-less". Now - here comes the nasty coincidence - I've also been writing some PHP code for our website that uses cookies (e.g. "shopping cart" and "user login" stuff). As the website is "example.tld" then I set the cookie on "example.tld" (the naked domain). The problem is that this also matches "ispconfig.example.tld", because the cookie domain rules match subdomains, so the cookie is also there for "ispconfig.example.tld" when I try to login to ISPConfig. And IDS does not like this one bit. It reports "Possible attack detected. This action has been logged." and I can't access ISPConfig to even login. Apparently, IDS does not like have this extra cookie there. It blocks access to ISPConfig completely when it's there. But if I go to my browser settings and delete the cookie, then IDS is happy and I can use ISPConfig with no issues. Is there some way to tell IDS that this particular cookie is okay and it should ignore it? As this "possible attack", as it labels it, is known not to be any external attack at all. It's my own code, my own cookie and these are all my domains / subdomains. Or, alternatively, is there any way - in PHP - to "setcookie" on a naked domain that doesn't include subdomains?
The problem is not the cookie itself, the problem is the content of that cookie, it must contain something that matches a script or sql or another attack pattern. You should be able to see more details in the system log in ispconfig monitor.
Ah, I think I might know what it could be. A value in the cookie is basically a JSON object. In the PHP, I do "json_encode" on an array and then store that - serialising it - but I guess it doesn't like that, as a JSON object does feature characters like {} and "", which are code-like constructs that could be tripping IDS's alarms. That's okay. Storing the JSON was, to be frank, just a development thing. A quick and easy way to dump and retrieve a few variables in one go. I was intending to make things more "elegant" than that anyway. But I guess this prompts me to do it now. Also, just after posting that, I did discover a way around it. If I don't specify any cookie domain, then it seems to auto-assume "just this domain only". But, as normal, I still prefer solutions to workarounds - to avoid nasty long-term bugs coming back to haunt you later - so I'll fix the cookie code anyhow.
